FIDO Validation Server — request a guided evaluation.
Demo access to the FIDO Validation Server is request-based: there is no public tenant signup and no open SaaS preview. Each evaluation is scoped to your authenticators, integration language, and timeline, and is run as a guided walkthrough with the engineering team.
What the demo will show
A working FIDO2 registration + authentication ceremony, attestation verification against an MDS mirror, and per-tenant policy enforcement — using the exact server image documented in the service page.
What we ask of reviewers
Tell us your tenant scope, target authenticators (security key / passkey / nano-card applet), and integration language. We'll provision a sandbox tenant + API keys within one business day and walk through the ceremony with you.
No data leaves the demo
Demo tenants are isolated, time-bounded, and torn down after the review window closes. No credentials, no test users, no relay metadata persists past the demo.
Request demo access
One email gets you a sandbox tenant, API keys, and a 30-minute architecture walk-through with our FIDO engineering team.
Read-now surface.
The runtime is locked behind a request gate, but the architecture, deployment posture, and standards positioning are public.
Service page
Multi-tenant SaaS architecture, attestation verification, MDS lookup, per-tenant policy, four-step enterprise onboarding.
FIDO evolution timeline
How the standard moved from FIDO 1.0 to passkeys, with the milestones our validation server tracks.
WebAuthn / passkey timeline
The W3C side — CredMan API → WebAuthn L3 → synced passkeys → per-credential provenance.
Understanding WebAuthn attestation
Cornerstone post on the attestation object the validation server verifies.
Passkeys vs traditional MFA
Where synced passkeys, hardware-bound passkeys, and OTP-based MFA actually sit on the security spectrum.
WebAuthn COSE algorithms
Reference table for the COSE algorithm identifiers the server accepts on registration.