Revision 4 of NIST SP 800-63B was published in July 2025 and the previous revision was withdrawn, so anything written against the old text is now describing a superseded document. The new revision keeps the structure that made the guideline useful: three authenticator assurance levels, each stated as a list of checkable requirements rather than an adjective.

AAL3 is the level people mean when they say authentication should be serious. It is worth reading against an unattended device, because the result splits three ways — requirements that fit exactly, requirements that do not apply because the threat they address is absent, and one that is not met at all unless the hardware was chosen with it in mind.

What fits exactly

The permitted authenticator combinations are narrow:

AAL3 authentication SHALL require one of the following authenticator combinations: Multi-factor cryptographic authentication; Single-factor cryptographic authentication used in conjunction with either a password or a biometric comparison

A certificate on a hardware token, unlocked by a PIN that the token itself checks, is the first of those combinations. The PIN is an activation factor for the authenticator rather than a secret sent anywhere.

The requirement that does the most work is about the key. In the summary table of AAL requirements, key exportability is permitted at AAL1 and AAL2 and prohibited at AAL3, and the reason appears in the text:

cryptographic authenticators used at AAL3 are required to provide a hardware-protected, isolated environment to prevent authentication keys from being leaked or extracted. Since syncable authenticators require the private key to be exportable, syncable authenticators SHALL NOT be used at AAL3.

This is the line that separates a hardware token from a credential file, and it is checkable on the device: the key object either reports itself as non-extractable and never-extractable, or it does not. Synced passkeys — which revision 4 otherwise accommodates at AAL2 — are excluded here by name.

Two more land cleanly. The authentication protocol at AAL3 must be replay-resistant, which a challenge-response exchange is by construction. And every authentication and reauthentication must demonstrate authentication intent from at least one authenticator — inserting a token and entering its PIN is an intentional act by the person, not something a background process can perform.

What does not apply, rather than what is met

Here the reading gets more careful. AAL3 requires the cryptographic authenticator to provide phishing resistance, and the guideline recognizes exactly two ways to get it:

Two methods of phishing resistance are recognized: channel binding and verifier name binding.

Channel binding requires the protocol to “establish an authenticated protected channel with the verifier” and then bind that channel’s identifier to the authenticator output. Verifier name binding ties the output to an authenticated verifier identifier. Both presuppose a verifier somewhere else — one that an attacker could stand in front of.

The same assumption is stated plainly elsewhere: communication between the claimant and the verifier is to occur over one or more authenticated protected channels.

On an unattended device there is no elsewhere. The verifier is the machine the engineer is standing in front of, and the exchange never crosses a network. There is no channel to bind and no remote name to authenticate, because there is no remote party to impersonate.

That is a real difference from a control being satisfied, and the honest way to put it is that the threat has moved rather than disappeared. What replaces a phishing attack is a tampered device: hardware or software altered to present a convincing prompt and capture what the token produces. Channel binding would not help against that even if it were possible. The answers are secure boot, software integrity and physical protection of the enclosure — different controls, in a different document, and an argument that has to be made rather than borrowed.

What is not met

AAL3 sets a bar on the hardware itself:

Single-factor and multi-factor authenticators used at AAL3 SHALL be validated to meet the requirements of [FIPS140] Level 1 or higher overall.

And the same for the verifying side: cryptography used by verifiers at AAL3 is to be validated at FIPS 140 Level 1 or higher.

This is not a design question. A token certified under a national scheme other than the American one — as is the case across much of the market this product serves — has no FIPS 140 validation, and no amount of correct protocol design supplies it. On such hardware AAL3 is not reachable as written, and a vendor claiming otherwise is either not reading the requirement or hoping you will not. With tokens that do hold FIPS 140 validation, the requirement is met by the choice of hardware rather than by the software around it.

Reauthentication is milder but worth stating. At AAL3 the overall timeout for reauthentication is required to be no more than 12 hours, and the inactivity timeout should be no more than 15 minutes. A service session on a machine is normally far shorter than 12 hours, so the hard limit is not the problem. The inactivity part belongs to the operating system’s session and screen-lock configuration, exactly as it does under PCI DSS and ISO/IEC 27002 — a sign-in mechanism does not get to claim it.

Honest boundaries

SP 800-63 is guidance addressed to US federal agencies. There is no certification body issuing an “AAL3 compliant” badge, and no product can carry the level on its own: an assurance level is a property of an authentication process as deployed, assessed by the organization relying on it. Tessera makes no such claim.

What the guideline is good for is precision. It gives a vocabulary in which “strong authentication” becomes a list — non-exportable keys, replay resistance, demonstrated intent, validated hardware, bounded session lifetime — and each item can be answered with yes, no, or not applicable here and this is why. Three of those answers above are yes, one is not applicable, and one is no unless you buy different tokens. That is a more useful thing to hand an assessor than a claim.

Sources