What is a embedded secure-element FIDO2 authenticator?

A FIDO2 applet running inside a CC EAL5+ secure element packaged as a removable nano-card (4FF) or a solderable MFF2 module. The credential is hardware-backed, origin-bound by the FIDO2 protocol, and stored under the issuer's GlobalPlatform security domain — not on the device's general-purpose enclave.

Can a embedded secure-element FIDO2 applet work as a roaming authenticator?

Yes. A removable nano-card can be carried between devices and behaves as a roaming authenticator over the host device's contact reader. A solderable MFF2 variant fixes the same applet into a single device as a platform authenticator.

Why use a embedded secure-element authenticator instead of a USB security key?

Because the secure element is already on the product's BOM — either as a removable nano-card or as a solderable MFF2 module — and is provisioned under the issuer's keys, not the device-vendor's. There is no extra physical part to ship, no second item to lose, and the credential's trust root sits inside an issuer-controlled secure element. For OEM and enterprise rollouts on devices that already carry a secure element, this collapses authenticator-hardware cost to zero.

Does the validation server need anything special to verify secure-element credentials?

No. The applet speaks standard CTAP2.1 and emits a standard attestation statement with an AAGUID. Any FIDO2 verifier that supports the applet's AAGUID in its policy will verify the credential exactly like any other hardware authenticator.

FIDOCornerstonePublished 2026-05-11Updated 2026-05-1113 min read

Embedded Secure-Element FIDO2 Authenticators for Enterprise Identity.

An enterprise FIDO2 credential that lives inside a CC EAL5+ secure element packaged as a removable nano-card (4FF) or a solderable MFF2 module — loaded under the issuer's keys, not the device-vendor's. One piece of silicon, one personalisation line, one revocation surface.

The shape of the problem

An enterprise rolling out phishing-resistant authentication faces a recurring procurement choice: USB security keys for every employee, smart cards on the badge line, or platform authenticators baked into the device. Each path has its operational tax. USB keys get lost. Smart cards need a personalisation line. Platform authenticators bind the credential to a device the user might replace twice in three years. What if the FIDO2 credential lived inside a secure element the product already carries on its BOM, loaded under the issuer's keys, and reissuable by the same personalisation line that issues every other secure-element credential?

That is the case for an embedded secure-element FIDO2 authenticator: a FIDO2 applet running on a CC EAL5+ chip packaged as either a removable nano-card (ISO/IEC 7810 4FF) or a solderable MFF2 module. The secure element is already certified. The personalisation pipeline already exists. The trust boundary already exists. Repurposing it as a phishing-resistant authenticator is a software question, not a BOM question.

What "embedded secure-element" actually means here

The silicon inside a 4FF card and inside an MFF2 module is the same CC EAL5+ secure element. The plastic-and-pads of the nano-card and the soldered footprint of the MFF2 module are simply two integration choices for the same chip. Both packages run JavaCard 3.x on top of GlobalPlatform 2.3.1; both load applets under the issuer's SCP03 keys; both behave the same to a FIDO2 verifier upstream.

A FIDO2 applet on this surface looks, to the host device, exactly like an external FIDO2 authenticator. It speaks CTAP2.1 over the contact (ISO/IEC 7816 T=0/T=1) interface. The applet generates and stores ECC P-256 keypairs inside the secure element; the private key never crosses the chip boundary, even to the device's own operating system. Registration and authentication ceremonies are origin-bound by the FIDO2 protocol itself.

Operationally, the applet has two modes:

Roaming (removable nano-card). The secure element is mounted in a 4FF card and is removable. The user can carry it between a phone, an SD-card reader, or a USB nano-card dongle and authenticate to whichever device is on hand. This maps cleanly to existing roaming-authenticator semantics in WebAuthn.
Embedded (solderable MFF2). The same secure element ships as an MFF2 module soldered to the host PCB. The applet behaves as a platform authenticator scoped to that device. This is the model for fleet-issued laptops, ruggedised industrial endpoints, and connected products where physical removal is an attack surface the OEM wants to eliminate.

Why a single secure-element surface matters

For an OEM that ships connected products, every device already carries a secure element for at least one purpose — key storage, signed update, device identity. The traditional split is: one secure element for the embedded baseline, separate authenticator hardware for user identity. Embedded secure-element FIDO2 collapses that into one piece of silicon under one issuer's keys. The OEM (or the enterprise running its own issuance) gets:

One certified secure element to validate, not two.
One personalisation line, not two.
One revocation surface (lost device or returned hardware revokes both device-identity and user-identity credentials together).
A FIDO2 authenticator that does not require the user to carry anything new.

For an enterprise that already issues hardware to its workforce, the gain is different: workforce identity that travels with the secure-element card rather than the device. A user upgrading from one device to the next moves the removable nano-card; their FIDO2 credentials move with it. Where the secure element is soldered (MFF2), the credential stays with the device and is reissued at hardware-refresh time through the same personalisation pipeline that loads every other applet.

The threat model gain

Platform authenticators on consumer phones rely on the phone vendor's secure enclave. That is fine for most threat models, but the credential is then bound to the vendor's lifecycle: a vendor breach, a forced OS update, or a lost device with the credential synced through the vendor's cloud all become operational concerns. Embedded secure-element FIDO2 changes the trust root: the credential lives on a CC EAL5+ chip whose attestation chain runs through an issuance CA the issuing organisation controls, not the device vendor.

For an enterprise or OEM that wants a phishing-resistant credential and wants the credential's trust root inside its own custody rather than the platform vendor's, embedded secure-element FIDO2 is the only widely deployable option. The next-cheapest alternative is a dedicated USB security key with its own issuance line: more hardware to ship, more cards to replace, more help-desk tickets when one goes missing.

How the credential flows in production

End-to-end, the registration ceremony on a embedded secure-element FIDO2 authenticator looks like this:

The relying party (running the FIDO Validation Server) emits a PublicKeyCredentialCreationOptions challenge scoped to the tenant.
The host device's WebAuthn client passes the challenge to the nano-card or MFF2 secure-element authenticator over CTAP2.1.
The applet generates an ECC P-256 keypair, scoped to the relying-party origin, inside the secure element. The private key is non-extractable.
The applet returns an attestation statement signed by the per-batch attestation key. The attestation includes an AAGUID identifying the applet model + firmware.
The validation server verifies the attestation, checks the AAGUID against the FIDO Metadata Service, applies the tenant's AAGUID allow-list, and persists the credential.

Authentication is the same flow with smaller cryptography: a challenge, a signed assertion, an MDS-free verification. The credential never leaves the secure element; the validation server never sees more than a public key and a signed counter.

Where this fits in an enterprise rollout

The right deployment shape for embedded secure-element FIDO2 depends on what the issuing organisation already ships:

OEM with a soldered MFF2 footprint. The applet ships on the device at manufacture. The end user sees a platform authenticator they did not have to install or pair. AAGUID and attestation cert get injected during the standard personalisation pass.
Enterprise running its own personalisation line. Issue nano-cards loaded with the FIDO applet under the enterprise's SCP03 keys. Workforce identity travels with the card; help-desk recovery is "issue a new nano-card" rather than "issue a new device + a new security key + a new badge."
Identity programme migrating from contact smart cards. The same applet that runs on an ID-1 contact card runs on the nano-card and on the MFF2 module. Issuers can mix form factors per population segment without changing the relying-party-side configuration.

Standards posture

The applet is designed against FIDO2 over CTAP2.1 with WebAuthn as the relying-party-side API. Cryptography is ECC P-256 with SHA-256, the FIDO Alliance recommended baseline. Personalisation runs over GlobalPlatform SCP03. AAGUID values are managed through the FIDO Metadata Service so verifiers can apply policy by authenticator class.

For a workforce rollout, the typical posture is to require attestation=direct, restrict to a small AAGUID allow-list (the issuer's nano-card or MFF2 applet plus a couple of fallback hardware keys for recovery), require user verification (PIN or biometric on the host device), and disable resident credentials except for explicit username-less flows.

What this is not

Embedded secure-element FIDO2 is not a replacement for every authenticator class. It is the right answer where:

The product or workforce population already needs a secure element on the BOM — for device identity, signed update, or smart-card credentials.
The credential needs to outlast the device, or be issued under issuer-controlled keys rather than the platform vendor's.
The trust root needs to live inside an issuer-controlled certified secure element rather than a consumer device's general-purpose enclave.

It is the wrong answer where the user has no device, where the deployment requires a passport-style ID-1 identity card, or where policy mandates a separate physical token for high-risk admin paths. In those cases, the workforce-identity rollout pairs embedded secure-element FIDO2 (daily sign-in) with a dedicated security key (admin escalation). The validation server handles both classes through the same AAGUID-based policy.

The deployment economics

Compared with issuing 5,000 dedicated USB security keys at roughly $40–60 each (per-key cost plus shipping plus help-desk burden for the first wave), a nano-card or MFF2 applet rollout is a one-time applet-load cost on a secure element the product or programme is already issuing. There is no new physical part. There is no second device to track. The recovery flow is the same as the issuer's existing secure-element replacement workflow.

The corresponding cost is integration: the validation server needs to be aware of the nano-card or MFF2 applet's AAGUID, the issuer's MDS entry has to be registered, and the relying-party identity stack needs to issue WebAuthn challenges through a backend that speaks the FIDO Validation Server's API. That integration work is one-time. The savings are recurring.

The bottom line

An embedded secure-element FIDO2 authenticator is a serious enterprise identity primitive, not a curiosity. It collapses the per-user authenticator hardware count to zero, places the credential's trust root inside an issuer-controlled certified secure element, and slots into existing CTAP2.1 + WebAuthn relying-party stacks without modification. For an OEM or enterprise that already ships secure elements on its products, this is the cheapest path to phishing-resistant workforce or device identity that actually scales.