The nRF93M1 provides hardware-anchored device security, authenticated and encrypted firmware, and standards-based transport security (TLS 1.2, TLS 1.3, DTLS 1.2).
Platform security
The nRF93M1 platform security is anchored in module hardware and includes the following hardware-backed mechanisms:
- Secure boot. A hardware root-of-trust verifies the authenticity and integrity of every firmware image loaded at power-on. Unsigned or tampered images are rejected.
- Flash encryption. Code and secrets stored in internal non-volatile memory are protected by on-chip flash encryption, tying the stored image to the device.
- Hardware true random number generator (TRNG). An on-chip TRNG seeds all cryptographic operations (TLS handshake ephemerals, key generation, nonces).
- Signed firmware update. Firmware updates are cryptographically verified against the root-of-trust before activation; failed verification triggers rollback to the previously known-good image. See Firmware update for supported firmware-update transports (HTTP and nRF Cloud).
Transport security
The nRF93M1 provides transport-layer security services built on Mbed TLS 3.6.5:
- TLS 1.2 and TLS 1.3 (RFC 5246, RFC 8446).
- DTLS 1.2 (RFC 6347), used for CoAP over UDP.
- DTLS Connection-ID per RFC 9146 for NAT resilience on power-saving cellular links.
- Up to 6 concurrent TLS contexts, each independently configurable for protocol, cipher suite, certificates, PSK identity, SNI, and session cache.
- Three security levels (
seclevel 0— no authentication,seclevel 1— server authentication,seclevel 2— mutual authentication).
The cipher suites exposed through the AT command interface (%SSLCFG) are
found in the nRF93M1 AT Commands.
Pre-shared-key (PSK) authentication is supported when both psk_identity and psk_key are configured on the same SSL context.
Credential storage
X.509 certificates, device private keys, and root CAs are stored as files in the module's file system. They are managed through the file system AT commands:
%FOPEN/%FWRITE/%FCLOSE— write a PEM-encoded credential (CA certificate, device certificate, or private key) to a named file.%FREAD— read back a stored file.%FDELETE— delete a stored credential file.%FSHA256— verify the SHA-256 hash of a stored file.
TLS contexts reference credentials by file path using %SSLCFG (for
example, "cacert", "clientcert",
"clientkey"). Credentials are retained across reset and power cycles.