"Passkey support" is one of the easiest claims in authentication to make and one of the hardest to check from the outside. The FIDO Alliance publishes conformance tools that drive a WebAuthn server through hundreds of valid and deliberately broken registrations and sign-ins. We ran them against Seamless Auth and published the results.
The result
On 2026-10-21, FIDO Conformance Tools 1.9.1 ran the full FIDO2 Server test plan against
seamless-auth-api 0.19.3: 159 passed, 0 failed, in about 22 seconds.
The tests cover:
- Registration and sign-in options: what the server asks the authenticator for, and that every challenge is fresh.
- Response structure: missing fields, wrong types, bad encodings, a challenge or origin that does not match. Most tests here are negative: a malformed response the server must refuse.
- Attestation formats:
packed(full and self),none,fido-u2f,tpmandandroid-key, including corrupted signatures, expired and misordered certificate chains, and keys that do not match. - Authenticator data: user verification flags, signature counters that fail to increase, and leftover bytes.
- The FIDO Metadata Service: revoked authenticators, compromised keys, and metadata that cannot be verified must all be refused.
What did not run, and what it found
Some tests are optional. They run only for the algorithms a server supports. Seamless Auth offers EdDSA, ES256, RS256 and RS1, so the optional PS256/384/512, RS384/512, ES384/512 and secp256k1 tests did not run. The results page lists each one.
One optional test is more interesting. With the tool's experimental "TPM ECDSA" option on, a TPM
attestation using an ES256 key fails. The key is fine. The WebAuthn library we use,
SimpleWebAuthn, parses the TPM key structure without reading two bytes that follow an ECDSA signing
scheme, so every later field comes out shifted and the key appears not to match. We reported it
upstream as SimpleWebAuthn#818, with the
exact bytes and a proposed fix. Until it is fixed, a TPM that describes an ES256 key that way cannot
register with attestation: 'direct'.
What this proves, and what it does not
This is self-validation, not certification. We ran public tools ourselves. The FIDO Alliance has not reviewed the results, and Seamless Auth is not FIDO Certified.
It is also worth knowing how the tools talk to the server. They use their own message format, so the
API exposes a small test-only interface when FIDO_CONFORMANCE_MODE is set, and never under
NODE_ENV=production. That interface uses the same verification calls, origins, relying party ID
and algorithm list as the real WebAuthn routes, so the cryptography and parsing being tested are the
production code. What it skips is everything around them: the pre-auth flow, session issuance, and
your deployment's authenticator policy. And because the tools sign everything with test keys, the
run trusts the tools' own test metadata and root certificate.
Android SafetyNet attestation is not covered at all: this version of the tools has no SafetyNet suite, and SafetyNet statements expire too quickly to test from saved fixtures.
Earlier runs earned their keep
The first runs, back in September, failed 15 tests. The cause was one bug: our conformance metadata loader did not read the tools' nested directory of statements, so every attestation looked like an unknown authenticator and was refused. A later run caught the server echoing an extension the tools had not asked for. Both were fixed long before 0.19. Neither would have shown up in our own tests, which is the argument for running someone else's.
What comes next
Interoperability testing and FIDO certification are on the roadmap for v1.0. Until then, the results page is where to look, and every future run will be published there with its tool version and date.