FedRAMP High and Moderate: How FIPS 140-3, AAL3, and IAL3 Actually Fit Together

A FIPS-validated security key can prove that a private key is protected by a tested cryptographic module. It cannot prove that the person holding it is the employee you hired.

That distinction is the center of a defensible FedRAMP identity program. Too many deployments begin with a shopping list of security keys and end with an auditor asking a much harder question: How did this specific authenticator become bound to this specific, identity-proofed person, and what prevents a weaker recovery path from undoing the control?

The answer crosses four different layers: FedRAMP controls, identity proofing, authentication, and cryptographic validation. They reinforce one another, but they are not synonyms. Treating them as interchangeable produces confident architecture diagrams and fragile systems.

This guide explains how the pieces fit together under the final NIST SP 800-63-4 Digital Identity Guidelines and FedRAMP's Consolidated Rules for 2026. It also gives security teams a better way to evaluate hardware authenticators: by the evidence and lifecycle they support, not by the logo printed on the key.

The short version: FIPS 140-3 validates a cryptographic module. AAL3 defines a high-assurance authentication event. IAL3 defines high-assurance identity proofing. The binding ceremony links the proven person to the authenticator. FedRAMP determines which controls and assurance outcomes apply to the service and its users.

Start With the 2026 FedRAMP Vocabulary

FedRAMP changed its operating model in June 2026. The program now describes certifications as Classes A through D, while agencies still categorize federal information systems as Low, Moderate, or High under FIPS 199.

That is not a simple rename. FedRAMP says the certification classes only loosely align with impact levels. Class C supplies enough information for most Moderate objectives and some High objectives, while Class D covers most unclassified use cases. The correct class depends on the agency use case, tailoring, and the assurance the authorizing official needs.

The current FedRAMP identification and authentication guidance is more concrete in two important ways:

• Multi-factor authentication for organizational, privileged, and non-privileged accounts must be phishing-resistant.
• IA-5 associates Class C with NIST digital identity assurance level 2 and Class D with level 3.

So the familiar shorthand of “Moderate means X” and “High means Y” is no longer precise enough on its own. A useful architecture states the FedRAMP certification class, the agency system's impact level, the applicable IA controls, the selected IAL/AAL/FAL for each user group, and any tailoring. If those five items are not visible, the word compliant is doing too much work.

Five Claims, Five Different Kinds of Evidence

The fifth row is routinely underfunded. It is also where identity proofing becomes access control instead of a one-time compliance exercise.

What AAL3 Requires Under NIST SP 800-63B-4

NIST's AAL3 requirements are demanding, but they are more precise than “use a hardware key.” An AAL3 authentication event requires:

• A cryptographic authenticator with a non-exportable private key.
• Phishing resistance, replay resistance, and a public-key protocol that protects authentication secrets from verifier compromise.
• A hardware-protected, isolated environment for the authentication key.
• Authentication intent, such as an explicit user action.
• Either a multi-factor cryptographic authenticator or a single-factor cryptographic authenticator used with a password or biometric comparison.
• FIPS 140 validation at Level 1 or higher overall for the authenticator and verifier cryptography.

Syncable passkeys do not qualify at AAL3 because their private keys are exportable by design. Device-bound authenticators can qualify only when the full implementation meets the requirements; “passkey” is not itself an assurance level.

The operational details matter just as much. At AAL3, the overall reauthentication timeout cannot exceed 12 hours, and NIST recommends an inactivity timeout of no more than 15 minutes. Reauthentication must use the same AAL3 strength as initial authentication. A security key deployed beside a 30-day session cookie is not an AAL3 session strategy.

What a FIPS 140-3 Certificate Covers

FIPS 140-3 tests a defined cryptographic module against security requirements. The certificate has a boundary, hardware and firmware versions, approved modes, caveats, a validation date, and a sunset date. Procurement must match all of them.

This is especially important during the final FIPS 140-2 transition. The NIST Cryptographic Module Validation Program states that FIPS 140-2 modules may be accepted for federal protection of controlled unclassified information through September 21, 2026. After that date, those certificates move to the Historical list and are limited to existing systems based on agency risk decisions. For new procurement, an active FIPS 140-3 validation is the safer planning baseline.

Do not accept “FIPS capable,” “uses FIPS algorithms,” or “built on a validated chip” as interchangeable with a validated product configuration. NIST recommends obtaining a vendor letter that maps the product to the certificate and confirms that the validated module supplies the relevant cryptographic services. The non-proprietary security policy should then tell your engineers how to initialize and operate it in the approved mode.

That last step is not paperwork. For example, the new YubiKey 5 FIPS Series ships with FIPS-approved mode off; administrators must initialize the applicable functions correctly before creating credentials. A validated module used outside its approved configuration is not rescued by the certificate number on the purchase order.

Setting Approved Mode Before Enrollment

Approved mode is set on the key itself, by whoever holds it before the user does. No identity provider can do it for you. Okta, Entra ID, and PingOne see the key only across the WebAuthn protocol, which gives them no way to inspect or change what is inside the module.

On the YubiKey 5 FIPS Series the mode applies per application, and an application enters it when its factory default secrets are replaced. FIDO2 needs a PIN. PIV needs a new PIN, PUK, and AES-192 management key. OATH needs a password, OpenPGP needs new user and admin PINs, and YubiHSM Auth needs a new management key. Yubico publishes a ykman command for each one, so the sequence scripts cleanly. U2F is disabled on these devices, so plan the deployment around WebAuthn.

Order matters more than the individual commands. NIST classified the 5 FIPS Series as composite authenticators, and an application cannot leave approved mode once initialized without being zeroized. A credential registered before the PIN was set does not become compliant afterward. Recovering means resetting that application, which destroys every credential on it, then enrolling the user again.

Checking the result is easy enough to make routine. Running ykman info prints a list of FIPS approved applications with a true or false value for each one, which gives you a per-device, machine-readable record to file alongside the binding evidence described below. The older --check-fips option applies to the YubiKey 4 FIPS Series and is not needed here.

At volume, Yubico's YubiEnroll handles reset, PIN setup, user verification settings, and registration against Entra ID, Okta, or PingOne from a single Windows command line, including enrollment on behalf of a named user. A ykman script does the same work with more control and sits naturally inside an attended session. Yubico will also pre-register keys before shipping them, which cuts labor but moves part of the ceremony to the vendor. Weigh that against the attended enrollment IAL3 expects.

Do not let the identity provider stand in for this check. Okta can restrict enrollment to approved models through its FIDO metadata and custom AAGUID lists, and the metadata it displays includes a FIPS compliance status. That status describes the model. It says nothing about the state of the key in the user's hand, and a factory-default FIPS key with no PIN set carries the same AAGUID as a correctly initialized one and will pass the allow list. Confirming approved mode belongs in the binding ceremony, recorded next to the credential ID and the proofing result.

What IAL3 Requires Under NIST SP 800-63A-4

IAL3 addresses a different failure: enrolling an impostor as a legitimate subscriber.

NIST SP 800-63A-4 defines IAL3 as on-site attended identity proofing. The proofing agent may be physically co-located with the applicant or participate remotely while the applicant uses a CSP-controlled kiosk or device. It is not an ordinary video call conducted through an applicant's unmanaged webcam.

IAL3 also requires qualifying identity evidence, validation against authoritative or credible sources, verification that the applicant owns the evidence, collection and retention of a biometric sample, trained proofing agents, protected proofing systems, and controls against manipulation and social engineering.

Most relevant to an AAL3 deployment, NIST requires the initial authenticator to be distributed or enrolled during an on-site attended interaction. If proofing and authenticator enrollment do not occur in one authenticated protected session, the CSP must compare a fresh biometric sample with the biometric collected during proofing before registering the authenticator.

That requirement exposes the weakness in a common remote-workflow design:

1. Run a strong identity check.
2. Ship a key later.
3. Let the user self-enroll through the same helpdesk and email channels used for ordinary accounts.

The first step may have reached IAL3. The third step can still break the chain.

The Binding Ceremony Is the Real Control

Our view is simple: a high-assurance authenticator should be treated as untrusted inventory until a controlled binding event links it to the proven identity and the relying party accepts the resulting credential.

A defensible binding record should link four objects:

1. The identity-proofing transaction and its assurance result.
2. The subscriber account and relying-party identifier.
3. The registered credential ID or public key.
4. Available authenticator evidence, such as the AAGUID, attestation chain, approved configuration, and device serial number when the technology supports it.

It should also record who supervised or approved the event, when it occurred, which protected session or device was used, and which exception path was invoked, if any. The point is not to accumulate data. It is to make the identity-to-credential relationship independently reconstructable without copying raw identity documents into every audit package.

AAGUID Is a Model Identifier, Not an Asset Tag

The Authenticator Attestation Globally Unique Identifier, or AAGUID, identifies a FIDO authenticator make and model. It does not normally identify an individual key. Standard attestation can prove that a credential came from an allowed authenticator type, while preserving the user's privacy.

That makes AAGUID allow-listing useful, but incomplete. It can stop an employee from registering a consumer key when policy requires a validated government model. It cannot tell you whether the enrolled key is asset 004271, whether that asset was shipped to this employee, or whether the same physical device moved to another account.

Enterprise attestation can add a device-specific identifier, such as a serial number, during FIDO2 registration. It requires compatible keys, client/platform support, relying-party support, and an explicit privacy decision. Where enterprise attestation is unavailable, combine ordinary attestation with controlled inventory and an attended observation of the device identifier. Do not pretend the AAGUID alone provides device-level custody.

A Current Hardware Authenticator Market Snapshot

The right question is not “Which key wins?” It is “Which exact hardware, firmware, protocol, IdP, and operating procedure can we defend together?” The public record below is current as of July 18, 2026 and should still be rechecked before purchase.

We intentionally left single-unit prices out of the table. Reseller pricing ages quickly and hides the real cost: spare authenticators, secure delivery, initialization, IdP integration, lifecycle tooling, recovery labor, and failed enrollments. A key that costs $20 less but cannot produce the attestation or inventory evidence your assessor expects is not cheaper.

The Seven Questions to Put in Every Security-Key RFP

1. What is the active CMVP certificate number? Require the certificate status, sunset date, security policy, caveats, and the vendor's product-to-module mapping.
2. Which exact versions are covered? Record hardware revision, firmware, applet, form factor, and any required initialization state.
3. Which protocol will produce AAL3? Name FIDO2/WebAuthn or PIV, the user-verification method, the verifier, and the permitted fallback methods.
4. What will the IdP verify at registration? Require attestation enforcement, AAGUID policy, metadata-chain behavior, and a plan for metadata or certificate rollover.
5. Can the organization identify an individual device? Document whether enterprise attestation, a PIV certificate, a serial read, or supervised inventory matching provides that linkage.
6. How are loss, reset, replacement, and revocation handled? Test the process before production and require two separately bound authentication means where continuity warrants it.
7. What evidence can be exported? The answer should include configuration, registration, assignment, revocation, and authentication records without forcing broad distribution of biometrics or identity-document images.

Why AAL3 Does Not Stop a Laptop Farm by Itself

Phishing-resistant authentication closes a major attack path, but it does not convert an authorized insider or domestic facilitator into the correct employee.

In April 2026, the Department of Justice announced sentences for two U.S. nationals who operated laptop farms that supported North Korean remote IT workers. The scheme used at least 80 stolen U.S. identities, reached more than 100 companies, and generated over $5 million. A company laptop in the United States can satisfy a location check while a remote operator controls it from abroad. A FIDO key attached to that laptop can still be activated by a local facilitator.

This is why identity assurance needs continuity. The proofing event establishes who the subscriber is. The binding event establishes which credential is theirs. Endpoint and access controls must still decide whether the present context is trustworthy.

For privileged or sensitive roles, useful supplemental controls include:

• Require the AAL3 credential from a managed, compliant endpoint and block unmanaged-device enrollment.
• Detect or prohibit unauthorized remote-control software, USB-over-IP, and unapproved peripheral forwarding on privileged workstations.
• Correlate credential registration and high-risk use with device posture, network risk, impossible travel, and recent account changes.
• Trigger a fresh attended identity check after suspicious recovery, a material location change, a new privileged role, or a break in device custody.
• Keep human investigation in the loop when signals conflict.

Continuous webcam monitoring is not the answer. It creates a large privacy and biometric-security liability while giving sophisticated operators another sensor to spoof. A better design collects the minimum evidence needed at explicit high-risk ceremonies and uses durable endpoint and credential telemetry between them.

A Practical IAL3-to-AAL3 Architecture

Trust Swiftly is designed for the point where high-assurance proofing has to become an enforceable credential decision:

1. Attended IAL3 proofing on controlled hardware. The applicant interacts with a trained proofing agent through a Trust Swiftly-controlled device or with a co-located agent. Evidence, biometric, device, and session controls support the required proofing ceremony.
2. Protected authenticator enrollment. The initial authenticator is enrolled in the same attended session, or the subscriber completes the required biometric comparison before a later registration.
3. Cryptographic and inventory evidence. The workflow records ordinary attestation, AAGUID, credential information, and a unique device identifier when supported, then links them to the identity decision.
4. Signed decision handoff. APIs and webhooks pass the minimum decision and binding evidence into the customer's IAM and audit workflow. Raw identity artifacts remain behind a more restrictive disclosure layer.
5. Customer-side enforcement. The customer's IdP, endpoint platform, and applications enforce the permitted authenticator models, protocols, user verification, session policy, device posture, and recovery rules.

That division of responsibility is important. Trust Swiftly can prove the person and create the binding evidence. The customer and its IAM stack must enforce how that credential is accepted. Buying either half without designing the handoff leaves an assurance gap.

See four practical identity-to-hardware binding patterns or review our FedRAMP IAL3 audit-evidence checklist for the artifacts to prepare with your assessor.

Recovery Is a New Binding Ceremony

Most high-assurance programs are strongest on enrollment day and weakest when someone says, “I lost my key.” That is exactly where an attacker will apply pressure.

Do not let a helpdesk reset, email link, SMS code, or manager's approval silently downgrade an AAL3 account. Revoke the missing credential promptly. Re-establish the subscriber's presence at the assurance required by policy. Register the replacement through the controlled binding workflow. Preserve the old and new credential identifiers, reason, approvals, timestamps, and revocation status in one chain of evidence.

NIST recommends encouraging subscribers to bind at least two separate authentication means to reduce recovery. For an AAL3-only population, that means two independently registered methods that can each satisfy the policy, not an AAL3 key plus an undocumented OTP escape hatch.

Frequently Asked Questions

Does FedRAMP Moderate require AAL3?

Not as a universal slogan. Under the 2026 model, FedRAMP Class C covers most Moderate objectives, and current IA-5 guidance associates Class C with digital identity assurance level 2. FedRAMP separately requires phishing-resistant MFA for organizational accounts. An agency, risk assessment, privileged role, or tailored control set may still justify AAL3. Document the applicable certification class, impact level, user group, and selected assurance level.

Does FedRAMP High require IAL3 and AAL3?

FedRAMP's current IA-5 guidance associates Class D, the class intended for the broadest and highest-impact unclassified use cases, with IAL, AAL, and FAL level 3. Confirm the exact scope and tailoring with the agency and assessor. A public-facing user population and an internal privileged workforce may have different risk decisions.

Does a FIPS 140-3 security key automatically deliver AAL3?

No. The key is one component. AAL3 also depends on the non-exportable credential, phishing-resistant protocol, activation factor or approved combination, verifier cryptography, authentication intent, reauthentication policy, and the absence of weaker fallback routes. The device must also be the validated version operated in its approved configuration.

Can IAL3 be completed remotely?

The proofing agent can be remote, but the applicant must participate in an on-site attended session through a CSP-controlled kiosk or device. An ordinary call using a personal webcam or unmanaged phone is not the IAL3 remote-agent pathway defined by NIST SP 800-63A-4.

Can a platform passkey meet AAL3?

A syncable passkey cannot meet AAL3 because its private key is exportable. A device-bound platform authenticator may meet NIST's technical criteria if its key, hardware protection, cryptography, activation, and protocol all qualify. However, FedRAMP IA-2(6) also requires one factor on a device separate from the system gaining access for the accounts in scope, so a roaming security key or PIV credential is often the cleaner FedRAMP architecture.

The Decision That Matters

Choosing a validated authenticator is necessary. It is not the hard part.

The hard part is maintaining one explainable chain from identity proofing to credential registration, policy enforcement, high-risk use, and recovery. Build that chain first, then buy the hardware that can produce the evidence it requires. That approach is more persuasive to an assessor, more resistant to real-world fraud, and far less likely to become an expensive key-distribution project with a compliance label attached.

Designing an IAL3-to-AAL3 workflow for a FedRAMP Class C or Class D environment? Talk with Trust Swiftly about controlled proofing, authenticator binding, and audit-ready evidence.