Configure hardware passkeys for FIPS and AAL3 requirements

Use this guide with your security administrator when deploying the Government passkey profile for a FIPS or authentication assurance level 3 (AAL3) requirement, including an applicable Class D deployment. It applies to commercial and government enrollments where this profile is available. Confirm the assurance level and required controls for your environment before configuring authenticators.

Government is an authenticator selection policy. It evaluates FIDO Metadata Service (MDS) certification and hardware metadata; selecting it does not certify a device configuration or your deployment. Your security administrator must confirm certificate applicability and the remaining authentication, session, and recovery controls.

Verify the authenticator configuration

Before purchasing or enrolling authenticators, complete these checks:

1. Identify the exact model, hardware revision, firmware version, and operating configuration. Devices in the same product family can have different validation coverage.
2. Find the applicable entry in the NIST Cryptographic Module Validation Program validated modules list ↗. Review the certificate status and the module's security policy with your security administrator.
3. Confirm that the certificate covers your exact configuration and that you can operate the authenticator in the required approved mode. Follow the vendor's initialization, firmware, and configuration instructions.
4. Confirm that the credential's private key is hardware-bound and non-exportable, and that the authenticator supports the user verification required by your deployment. A touch for user presence alone is not user verification.
5. Confirm that the authenticator is accepted by the current Government profile. A CMVP certificate alone does not guarantee profile membership; the profile also requires applicable FIDO certification, hardware key protection, and exclusion of software, synced, and compromised authenticators.

The current Government derivation includes the requirements of Recommended. It also requires MDS evidence of FIPS overall level 1 or higher and physical-security level 3 or higher for the same FIPS revision. A metadata entry is supporting evidence, not a substitute for checking the certificate's scope and configuration requirements.

If a device is not eligible, contact Palantir Support and your security administrator. Do not use a Custom addition as evidence that the device meets a FIPS or AAL3 requirement.

YubiKey 5 FIPS Series configuration example

The vendor's deployment guide ↗ documents YubiKey 5 FIPS Series firmware 5.7.4 as FIPS 140-3 validated at overall security Level 2 and physical security Level 3. Review its firmware and validation reference ↗. Confirm your exact model's CMVP certificate and acceptance by your directory's current Government profile before purchasing or enrolling it.

Follow the vendor's FIPS 140-3 configuration instructions ↗ to initialize the FIDO2 application in approved mode before creating passkeys. Firmware 5.7.4 requires a FIDO2 PIN of at least eight characters and enforces user verification. Follow its FIDO2 requirements ↗, then complete the registration and sign-in checks below.

Firmware 5.4.2 and 5.4.3 use different FIPS 140-2 validations and initialization instructions. If you already use these devices, review their certificate status and continued use with your security administrator. The vendor's deployment guide distinguishes existing deployments from new deployments; do not assume the firmware versions have interchangeable validation coverage.

Prepare administrator access

Plan recovery before tightening the policy:

• Identify the administrators and users affected by the change.
• Arrange accepted replacement hardware and a recovery method approved for your assurance level.
• Maintain an accepted spare credential where your organization's policy permits it, and protect it according to that policy.
• Confirm that both ordinary sign-in and administrator recovery meet your environment's requirements. A recovery email or one-time code alone is not evidence of AAL3.

Review the profile impact preview. Register an accepted hardware passkey for the acting administrator before changing the enforced profile; a change that would leave that administrator without an accepted passkey is rejected.

To apply Government to the directory, open Manage user directories in Control Panel, select the directory, and open its passkey policy settings:

1. Select Government as the profile.
2. Select Check impact and review the affected users. Arrange accepted replacements and review the impact again before continuing.
3. Select Enforce to open the confirmation dialog. This action is unavailable if the preview shows your own administrator account would be left without an accepted passkey.
4. Enter a Reason for change, which is required for every policy change.
5. Review the impact, then select Enforce or Enforce anyway to confirm. The change is recorded in the profile-change audit event.

Register and verify a hardware passkey

Follow this sequence for each user:

1. Initialize the authenticator using its approved configuration and configure its required PIN or other supported user-verification mechanism.
2. Use the directory's add-passkey workflow to send the user an enrollment invitation.
3. Complete registration with the intended hardware authenticator. Permit manufacturer attestation when requested by the supported browser and platform flow.
4. Confirm that registration succeeds under the Government profile. MDS-listed registrations must establish trusted attestation; an AAGUID match or a device name is insufficient.
5. Sign out, then verify a fresh sign-in using the new credential and required user verification. Confirm that the expected profile remains enforced.
6. Retain the certificate, device configuration, and registration evidence required by your organization's assessment process. Remove superseded credentials after verifying replacement access and following your retention policy.

Confirm deployment controls

Work with your security administrator to verify the full assurance requirement. In addition to authenticator selection, review user verification, verifier configuration, protected communications, session lifetime, repeat authentication, account recovery, and authenticator replacement procedures. Use the requirements applicable to your accreditation and the NIST SP 800-63B authenticator assurance levels ↗, the broader NIST digital identity guidelines ↗, and FedRAMP IA-05 authenticator management ↗.

MDS updates can change profile membership. Review the current effective policy when replacing devices, upgrading firmware, or investigating new registration failures. Maintain your own confirmation that deployed models and configurations remain covered by the required certificates.

Replace a lost or rejected authenticator

If an accepted spare is available, use it to sign in and register a verified replacement. Otherwise, use the recovery process approved for your environment with an authorized administrator. Follow the passkey management instructions to remove a lost credential or arrange re-registration.

For a rejection, check the exact AAGUID, model and firmware, profile membership, MDS security status, and attestation result. A software or self-attested credential cannot be made into verified hardware by changing its display name or adding its AAGUID to Custom.

If no usable metadata snapshot can be loaded, retry after service recovery or contact Palantir Support. Do not weaken the profile solely to bypass a verification failure.

Request a FedRAMP exception

FedRAMP administrators can select Recommended or Government without a profile exception. To select Standard, Permissive, or Custom, contact Palantir Support for the required FedRAMP change-review and Security Compliance approval process.

Approvals distinguish two cases:

• A profile exception within the combined MDS, Standard, and Recommended authenticator sets
• A separate exception for authenticators outside that combined set, which also requires the first approval

The check covers every authenticator in the effective profile, including those inherited from a Custom base. A broad built-in profile can therefore require both approvals. Approval is specific to your enrollment and must be applied before the additional choices can be used. Approval alone does not change the directory's stored profile.

Neither approval waives attestation, security exclusions, administrator permissions, or self-lockout protection. Standard membership alone does not establish AAL2; required user verification and the other controls applicable to your deployment remain necessary.