Treat access control, transport encryption, device identity, and stored resources as separate integration decisions. Start with the interfaces needed by your application and add provider-specific key protection when required.

Requirement	Start here
Authenticate users and authorize routes	Authentication and authorization
Accept HTTPS connections	HttpSharkSslServCon and its certificate setup
Require a trusted HTTPS server when acting as a client	HttpClient::setSSL and HttpClient::setAcceptTrusted; inspect the result with HttpClient::trusted
Register and renew a native device certificate	SharkTrustX C Client
Integrate a PSA Crypto key provider	Getting Started with PSA Crypto
Verify packaged application resources	Signed and Encrypted ZIP files

For HttpClient, configure the SharkSSL trust context and call setAcceptTrusted(true) before the first request. This rejects untrusted new connections before sending HTTP request data. Calling trusted() alone only queries a result; it does not enable enforcement. Changing the policy does not recheck an already reused connection, so close it before changing policy.

The authentication, listener, and native client APIs can be used from BAS or BWS when their implementations are linked. The PSA getting-started guide below concerns the BAS Lua TPM API, including Mako and standalone Xedge. Native BWS PSA users should start with the SharkTrustX C integration and its Windows example. The signed-ZIP guide concerns BAS Lua application loading; it does not enable signature verification for arbitrary native ZipIo mounts.

SharkSSL has a separate native API reference. Provider support, product configuration, and formal cryptographic validation are distinct. Consult the relevant provider and deployment requirements.