The FIDO Alliance has introduced a certification framework for digital identity wallets. If your team issues credentials, manages federated access, or evaluates wallet implementations, understanding this certification's impact on your trust boundaries and interoperability requirements is essential.
This checklist guides you through assessing readiness for adopting FIDO-certified wallets. It covers technical prerequisites, implementation validation, and phishing-resistance verification. Each item details the specific requirement and what "done" looks like in production.
What This Checklist Covers
This checklist is for organizations evaluating digital identity wallets against FIDO's new certification framework. You'll validate:
- Phishing-resistant authentication requirements (FIDO2 compliance)
- Cryptographic binding between credentials and authenticators
- Cross-platform interoperability for multi-vendor environments
- Federation metadata exchange for wallet-to-relying-party trust
Use this if you're a CISO planning wallet adoption, an IAM architect evaluating vendors, or a compliance lead mapping certification to your control framework.
Prerequisites
Before starting, confirm:
You understand your credential issuance model. Do you issue verifiable credentials directly, or rely on third-party identity providers? Wallet certification impacts both paths differently.
You've mapped your relying parties. List every application, service, and partner that will consume credentials from the wallet. Each relying party must support the wallet's authentication protocol.
You have a phishing-resistance requirement. If your threat model doesn't prioritize phishing resistance, wallet certification may not be your primary concern. Focus on OAuth 2.0 hardening first.
Checklist Items
1. Verify FIDO2 compliance for all authenticators
Requirement: Every authenticator bound to the wallet must meet FIDO2 specifications for phishing-resistant authentication.
How to validate: Check that your wallet implementation uses WebAuthn for credential binding. The authenticator should generate a public-private key pair, with the private key stored in secure hardware (TPM, secure enclave, or Multi-Factor Cryptographic Device).
What good looks like: Your authentication flow never transmits shared secrets. The wallet signs challenges with private keys that never leave the device. You can demonstrate phishing resistance by showing that credentials cannot be replayed across origins.
2. Confirm cryptographic binding between credential and authenticator
Requirement: The wallet must cryptographically bind each credential to a specific authenticator, preventing credential theft or replay attacks.
How to validate: Review the wallet's key management architecture. The credential issuer should receive a public key during enrollment. Subsequent authentication attempts must present proof of possession for the corresponding private key.
What good looks like: If an attacker steals a credential from your database, they cannot use it without the bound authenticator. Your incident response plan no longer treats credential compromise as an automatic authentication bypass.
3. Test cross-platform interoperability with your relying parties
Requirement: Certified wallets must support standardized protocols that work across vendors and platforms.
How to validate: Deploy a test wallet and attempt authentication against your critical relying parties. Document any custom integration work required. Repeat with a second vendor's wallet implementation.
What good looks like: You can swap wallet vendors without rewriting relying party code. Your federation metadata exchange works with any certified wallet. User accounts remain portable across platforms.
4. Validate federation metadata for wallet-to-relying-party trust
Requirement: Your relying parties must consume and validate federation metadata from the wallet provider.
How to validate: Inspect the metadata exchange during authentication. Confirm that your Policy Decision Point verifies the wallet's signing certificate against a trusted root. Check metadata refresh intervals.
What good looks like: Your relying parties automatically reject credentials from non-certified wallets. Metadata updates propagate within your defined SLA (typically 24 hours). You have monitoring in place for metadata validation failures.
5. Map certification to your compliance framework
Requirement: Document how FIDO wallet certification satisfies specific controls in your compliance framework (NIST 800-63, SOC 2, ISO 27001).
How to validate: Create a traceability matrix linking FIDO certification requirements to your control catalog. Identify any gaps where certification alone isn't sufficient.
What good looks like: Your auditors accept FIDO certification as evidence for phishing-resistant authentication controls. You have clear documentation showing which controls require additional implementation beyond certification. Your risk register reflects reduced likelihood for credential phishing attacks.
6. Establish wallet lifecycle management procedures
Requirement: Define processes for wallet enrollment, credential issuance, revocation, and recovery.
How to validate: Document the end-to-end lifecycle. Test credential revocation propagation time. Verify that lost device scenarios have a defined recovery path that doesn't bypass phishing resistance.
What good looks like: Your help desk can revoke wallet credentials within 15 minutes of a report. Users can recover access without falling back to phishable authentication methods. You have metrics on wallet adoption rates and authentication success rates.
Common Mistakes
Treating certification as a binary security decision. Certification validates specific technical requirements. It doesn't evaluate your key management practices, recovery procedures, or user enrollment workflow. You still own the risk.
Assuming all certified wallets are interchangeable. Certification defines minimum requirements. Vendors add proprietary features that may lock you into specific ecosystems. Test interoperability before committing to a vendor.
Skipping the relying party compatibility assessment. Your legacy applications may not support the authentication protocols required by certified wallets. Budget for relying party upgrades, not just wallet deployment.
Ignoring the user experience implications. Phishing-resistant authentication introduces friction. Users who lose devices need recovery paths. Plan for support volume increases during rollout.
Next Steps
Score your current state against items 1-6. Identify gaps that block wallet adoption.
Prioritize relying party upgrades. Start with your highest-risk applications. These benefit most from phishing resistance.
Run a pilot with a certified wallet. Choose a low-risk user population. Measure authentication success rates and support ticket volume.
Update your authentication policy. Define when wallet-based authentication is required versus optional. Map this to your data classification scheme.
Wallet certification creates a trust anchor for digital identity. Use this checklist to validate that your implementation earns that trust.
