Platform Security Architecture (PSA) Crypto separates cryptographic calls from the implementation that owns keys and performs operations. SharkSSL supports both sides of that boundary through separately built components.

Component	Role	Configuration and source
SharkSSL PSA consumer	TLS and application adapters call an external provider's `psa_*` API.	`SHARKSSL_PSA_CONSUMER=1`, `src/psa-consumer`, and the chosen provider's headers/library.
SharkSSL PSA provider	Implements a documented subset of `psa_*` using SharkSSL cryptography.	`src/psa`, `inc/psa/crypto.h`, and the provider build options.
Native SharkSSL	Uses the native crypto implementation without the external-provider consumer path.	Native library sources and the selected processor backend.

A consumer can use the SharkSSL provider or another compatible provider. Use one provider in the application. Provider version numbers, a key-handle API, and successful linking do not establish algorithm support, certification, or hardware protection.

SharkSSL PSA consumer gives the adapter source/header mapping, build commands, provider requirements, and standalone crypto boundaries.
SharkSSL PSA Crypto provider describes the supplied provider's supported subset, key storage, driver registration, and resource limits.

Keep key ownership explicit

TLS certificate-registration calls borrow the application's signing handle. In contrast, consumer key contexts such as SharkSslPSAEcdsaKey own volatile keys they create/import and require their destructor before reuse. The key wrapping API returns a new caller-owned key on successful unwrap. Read each API's lifetime and failure contract rather than treating every handle alike.

The SharkSSL provider's storage/driver callback tables are copied at registration, but their contexts remain borrowed. Register them at the required quiescent point. Their callbacks run under the provider lock and must not re-enter PSA or registration functions.