Which keys //AIRGAPT accepts, and why it isn’t a certification list.
//AIRGAPT reads each authenticator’s statement from the FIDO Alliance Metadata Service (MDS3) and admits it on one property: that its key material is non-exportable. Certification level tells you what was audited, it does not tell you what the device is.
We gate on the property, not the badge.
//AIRGAPT does not gate on certification level. //AIRGAPT gates on the security property itself, read from the MDS statement for each AAGUID:
- Required: keyProtection includes
hardware,secure_elementortee. - Rejected: software-only key protection.
- Required: attestation is present and verifiable against MDS, root certificates populated, and self-attestation (
none/basic_surrogate) rejected.
Why this is the better gate:
- →It gates on what the device does (non-exportable key material), not on whether the vendor purchased an audit. FIDO’s own certification materials note that L1 examples include “Level 2- or Level 3-capable authenticators that have not yet been certified at Level 2 or Level 3”, certification is a paid, optional evaluation (L2 requires a FIDO-accredited lab; L3 adds hardware penetration testing). Many genuine hardware keys sit at L1 because the vendor never submitted them.
- →It admits every hardware-backed authenticator regardless of certification level, so customers are not forced to re-buy keys they already own.
- →It is more defensible than a badge: the property is verifiable per-device from MDS, not asserted by marketing.
Supporting note, traceable to the FIDO Authenticator Requirements: a roaming authenticator attached over USB, BLE or NFC is treated as an intrinsically restricted operating environment, the key never leaves it. This is the property the gate depends on.
Why software-backed keys cannot be admitted.
In a working-time or wage dispute, the party with both the motive and the administrative control of the endpoint is the employer. //AIRGAPT’s claim to a tribunal is that the employer cannot alter the record. If key material could be extracted by someone holding administrator rights on the machine, that claim would fail in precisely the dispute the product exists to serve. Hardware-backed key protection is therefore the floor for every tier, including Workforce, not only for high-assurance deployments. Workforce is not a relaxed tier.
Three tiers. One floor. Workforce is not relaxed.
The constraint FIDO publishes, and we show it.
At L1, L1+ and L2 the authenticator is not required to restrict its private key to signing only valid FIDO messages, that constraint begins at L2+ (Authenticator Requirements 2.1.15). In principle the to-be-signed object could be constructed outside the authenticator. Producing a signature still requires possession of the key, so this does not undermine attribution, but //AIRGAPT states it openly rather than leaving it for an evaluator to raise.
Will my existing keys work?
Any FIDO2 authenticator with hardware-backed key protection and verifiable attestation qualifies for the baseline tier, regardless of whether the vendor paid for L2/L3 evaluation. //AIRGAPT is vendor-neutral by design (FIDO2 / CTAP standards, no single-vendor SDK dependency), and our reference implementation is validated across more than one manufacturer.
MVP scope: Windows endpoints. Support for additional platforms is on the roadmap.
The authenticators, as FIDO publishes them.
Certification level shown for reference only, it is not the admission gate. Data: FIDO Metadata Service (MDS3) · mds3.fidoalliance.org. Admission is computed per-device from keyProtection, attestationTypes and attestationRootCertificates.