Register for part 2 of our Device Identity Webinar Series!

Hardware-backed device identity for NIST-aligned authentication

SP 800-63B-4 sets the requirements for phishing-resistant user authentication, including a non-exportable key at AAL3. Smallstep strengthens the device side of access: certificates issued under inventory policy, with keys bound to hardware and attested where the platform supports it. A device certificate authenticates the device; it contributes to a user's assurance level only where your identity provider binds it to that user and accepts it as an authenticator. Otherwise it is a separate device condition.

Get a demo
background gradientbackground texture
Non-exportable keys where hardware attests
Client-authenticated TLS, named by 800-63B-4
A device condition unless your IdP binds it
Works alongside Entra and Okta
Records per credential for the assessor
No AAL claim: your IdP and hardware decide

Keys bound to hardware, with assurance that varies by platform

On attested enrollment paths, TPM-backed agent enrollment on Windows, Linux, and ChromeOS and ACME device attestation on supervised Apple devices, the device key is generated in the secure element and its provenance is proven to your inventory before issuance; it cannot be exported or synced, the property 800-63B-4 requires at AAL3. The credential an application then uses may be that key or a provisioned one with less protection; the macOS agent path uses Smallstep attestation, which does not establish hardware provenance to the same degree.

  • Levels are documented per workflow and application.

Client-authenticated TLS is phishing-resistant where it is the authentication

800-63B-4 cites client-authenticated TLS, as used by PIV and CAC, as a phishing-resistant protocol with channel binding: the signature is bound to the channel, so a look-alike site or relay cannot reuse it. That protection covers the protocol and verifier where the certificate is the authentication, such as EAP-TLS at the network or certificate sign-in at the identity provider. A device check consulted during SSO, or mutual TLS at a relay, is device enforcement; it does not by itself make the user's sign-in or the downstream session phishing-resistant.

Device condition or subscriber authenticator: your IdP decides

Where an identity provider maps a certificate to the user and accepts it in sign-in, as Entra certificate-based authentication does, the certificate is a single-factor cryptographic authenticator, and the administrator decides through binding policy whether it is treated as single-factor or multifactor. That designation does not itself meet AAL3. Where the IdP instead consults Smallstep as a device check, as the Okta integration does, the user's factors are unchanged and the certificate is a device condition.

What stays outside the certificate

Authentication intent comes from an authenticator that requires user interaction, such as a locally verified activation factor controlling the key; a silently selected certificate does not supply it. The 12-hour reauthentication maximum and the recommended 15-minute inactivity timeout at AAL3 are session policy at your identity provider and relying parties. FIPS 140 validation of the authenticator and verifier cryptography is required for AAL3 conformance and depends on your hardware and modules. None of these is set by the certificate.

Evidence for the system security plan

Every certificate issued through the device enrollment workflow maps to an inventory record: the device, its enrollment method and key protection level, the assigned user where there is one, and issuance, renewal, and revocation history. With your verifier's authentication logs, that supports assessment of the device credential and its use in authentication. An assessor may also ask for authenticator-binding records, module validations, and verifier configuration.

Smallstep supplies the hardware-bound device credential and its record. Your identity provider and hardware decide the assurance level.

Key benefits for NIST-aligned access design

Non-exportable device keys

Generated in the TPM or Secure Enclave on attested enrollment paths, never exported or synced. The key property 800-63B-4 requires of an AAL3 authenticator, on the device side.

A phishing-resistant exchange

Where the certificate is the authentication, EAP-TLS or certificate sign-in, the exchange is channel-bound and nothing is typed. No password or code to capture.

Device authorization at enrollment

A certificate is issued only to a device in your inventory that passes enrollment policy, attested against its endorsement key or Apple attestation where the path supports it.

Works alongside Entra and Okta

Hardware-backed device identity that complements Entra and Okta access policies. Using a Smallstep-issued certificate for Entra user sign-in is a separately validated certificate and authentication configuration.

Records per credential

Enrollment method, key protection level, assigned user, and issuance and revocation history per device, alongside the verifier's own logs.

Automated certificate lifecycle

Short-lived credentials renewed by the agent or your MDM, expiry visible per device, and revocation available where your verifiers check status.

Strengthen device access with hardware-bound credentials.

Hardware-backed device credentials, an attested inventory, enrollment controls, automated lifecycle, and enforcement at Wi-Fi, VPN, ZTNA, and your identity provider. We will show which hardware in your fleet can attest and where each control fits your 800-63B-4 design.

Book a demo

FAQs Smallstep for NIST SP 800-63B

Revision 4, final in July 2025, defines phishing resistance as a property of the authentication protocol: preventing disclosure of authentication secrets without relying on the claimant's vigilance, through channel binding or verifier name binding, with client-authenticated TLS as its channel-binding example. Passwords and anything requiring manual entry of an authenticator output are not phishing-resistant, though a password remains permitted as a second factor. Verifiers must offer at least one phishing-resistant option at AAL2, and federal agencies must require it for staff, contractors, and partners. At AAL3 the authenticator must have a non-exportable private key in a hardware-protected environment, and syncable authenticators are excluded. The assurance levels describe how a person authenticates; the guidelines do not address machine-to-machine authentication.

Authentication with a certificate inside a client-authenticated TLS handshake is phishing-resistant under 800-63B-4, because the secret is never disclosed and the signature is bound to the channel. Whether it is a user's MFA is a different question. A device certificate authenticates the device. It counts toward the subscriber's authentication only where the identity provider binds it to that user and accepts it as an authenticator; even then it is single-factor until paired with an activation factor or second authenticator the IdP configures. Where the IdP only consults it as a device check, the user's MFA is whatever the IdP already requires.

No product does. AAL3 requires a non-exportable key in hardware, phishing resistance, replay resistance, verifier-compromise resistance, authentication intent, an activation factor or second authenticator, reauthentication at most every 12 hours (with a 15-minute inactivity timeout recommended), no syncable authenticators, and FIPS 140 validation of the authenticator and verifier cryptography. Smallstep supplies hardware-bound device credentials, attested where the platform supports it, and the records behind them. Whether a certificate is a subscriber authenticator at all depends on how your identity provider binds and accepts it; the rest is your IdP, your hardware, and your policies, and an assessor decides whether the whole meets the level.

Phishing resistance through channel binding: client-authenticated TLS, for the exchange it is used in. Non-exportable key in hardware: on attested enrollment paths; provisioned credentials are lower assurance. Verifier-compromise resistance: verification by public key and certificate trust, no shared secret at the verifier. Replay resistance: each handshake is signed with a fresh nonce. Multi-factor, or single-factor plus password: only where the certificate is bound to the user and accepted as an authenticator, configured at the IdP. Authentication intent: an authenticator with user interaction, not a silent certificate. FIPS 140 validation: your hardware and modules, confirmed against the CMVP. Reauthentication, 12 hours required and 15 minutes recommended: session policy at the IdP and relying parties. No syncable authenticators: device keys are not syncable.

Two different things are possible and should not be confused. Entra certificate-based authentication is user sign-in with an X.509 certificate mapped to the user account; the certificate must meet Entra's trust, username-binding, and policy requirements, defaults to single-factor, and an administrator can mark an issuer or policy OID as multifactor through binding policy. That designation is an administrative assertion, not evidence that AAL3 is met, so keep certificates without an activation factor at single-factor and combine them in a Conditional Access authentication strength. Smallstep's documented Entra position is issuance-time device assurance on top of Entra's own controls; using a Smallstep-issued certificate as the Entra CBA user credential is a separate design that needs end-to-end validation.

As a device condition, not a user authenticator. Okta keeps managing users and MFA. Smallstep integrates as an external device identity check that Okta consults during sign-in using OIDC and mutual TLS, so sign-in can require a device in your inventory. The user's phishing resistance comes from Okta's own authenticators, such as FastPass or FIDO2; the Smallstep check adds proof of which device, bound to hardware where the platform supports it, and does not change the user's AAL.

It varies by model and firmware. Many discrete and firmware TPM 2.0 implementations hold FIPS 140-2 or 140-3 validations; check the specific hardware in your fleet against the NIST CMVP list. Apple validates its corecrypto modules, including those used by the Secure Enclave, but the validated boundary and version differ by OS release. AAL3 conformance requires validated authenticator and verifier cryptography, so document the validation for each device class rather than assuming it. Smallstep does not assert FIPS status for your endpoints.

Some applications cannot use a hardware-bound key directly. On those paths the Smallstep agent authenticates to the CA with the device's hardware-bound key and receives a short-lived credential the application can use, protected by the operating system rather than the secure element. The protection level is documented per platform and application. The device behind them was enrolled under inventory policy, attested where the enrollment path supports it, but the provisioned key is not hardware-protected, so do not count it toward the AAL3 non-exportable requirement.

Not from the certificate. 800-63B-4 requires the authenticator itself to establish intent through an explicit user action. A device certificate selected silently by the operating system does not demonstrate it, and unlocking the device is not by itself an authentication event. A multi-factor cryptographic authenticator can establish intent through its locally verified activation factor, the PIN or biometric that controls access to the key, entered for that authentication. A separate password prompt at the identity provider is a different authenticator arrangement: it may be the second factor, but it does not activate the certificate's key.

Both are phishing-resistant cryptographic authenticators. Synced passkeys are excluded at AAL3 because the private key is exported to a cloud account; device-bound passkeys are not. Certificates cover places passkeys do not reach, such as EAP-TLS Wi-Fi, IPsec and SSL VPN, and mutual TLS to services, and they identify the device rather than the user. Many designs use a device-bound passkey or FastPass for the user factor and a Smallstep device certificate for the device condition.

800-63 is binding on federal agencies and a reference for everyone else. Some cyber insurers, assessors, and auditors applying "phishing-resistant MFA" requirements borrow its definitions, as does CISA's phishing-resistant MFA guidance, which names FIDO/WebAuthn and PKI-based authentication, and security teams use it to write policy. An organization outside federal scope can adopt individual requirements without claiming full conformance. Using the terms correctly, including the difference between a phishing-resistant device credential and a user's multifactor authentication, keeps claims defensible in those reviews.

Not on its own. 800-171 Rev. 2 3.5.3 (Rev. 3 03.05.03) asks for multifactor authentication of users. Rev. 2 3.5.2 covers authentication of users, processes, or devices; Rev. 3 separates device identification and authentication into its own requirement, 03.05.02. A device certificate addresses the device side of that control. It can be part of a user's multifactor design only where the identity provider binds and accepts it as that user's authenticator; the user MFA requirement is met by the IdP's configuration. See the public sector page for the control mapping.

Nothing, by itself. Revocation stops the next authentication where the verifier checks status: Smallstep RADIUS checks on every authentication, and other verifiers check CRL or OCSP on their own schedule. An established application session continues until the relying party enforces reauthentication or ends it. At AAL3 the guidelines require reauthentication at least every 12 hours and recommend a 15-minute inactivity timeout; those bounds limit the window only where the identity provider and relying parties enforce them.

Per device: how it was enrolled, whether the key was attested and in which secure element, which user is assigned, when each certificate was issued, renewed, and revoked, and when the device left inventory. Together with your identity provider's authentication and authentication-strength logs, that supports assessment of the device credential and its use in authentication. Certificate records do not replace the verifier's logs, which show the factors actually used at sign-in, nor the binding records, module validations, and verifier configuration an assessor may also request. Section references are to NIST SP 800-63B-4.