How a Hardware Security Key Is Made: Secure Elements, FIDO, Firmware

A hardware security key is a small certified chip, usually a secure element or a hardened microcontroller, mounted on a tiny circuit board with a USB connector, often an NFC antenna, a touch sensor and an LED, then sealed in a potted or welded plastic case. At the factory the chip receives its firmware and an attestation key and certificate that prove which model it is.

Before it ships, the design passes FIDO Alliance functional and security certification, the chip underneath it usually carries a Common Criteria evaluation, and some models add a NIST FIPS 140-3 validation. On most keys the firmware is fixed for life, which is a security choice with a real cost. This guide follows a key from silicon wafer to tamper evident box, explains what each certification actually tests, and shows how to check the model and firmware of the keys you already own. It goes one level below our explainer on FIDO2, WebAuthn and CTAP, which covers the login protocol, and our guide on why you need two security keys. Every level, date and field name below was checked against the primary sources listed at the end.

Key takeaways

• The security of a key lives in one chip. On most keys it is a secure element designed and evaluated against Common Criteria smart card protection profiles; on others it is a general purpose microcontroller with readout protection.
• FIDO certification has two halves: functional certification (does the key speak CTAP and WebAuthn correctly and work with real clients) and authenticator security certification at levels L1, L1+, L2, L3 and L3+.
• L3 maps to Common Criteria vulnerability analysis AVA_VAN.3 or higher and L3+ to AVA_VAN.4 or higher, according to the FIDO Authenticator Security Requirements.
• The attestation key is usually shared by a batch. FIDO requires each batch to be at least 100,000 keys so the attestation key cannot become a tracking handle; smaller runs must all share one key.
• The AAGUID, a 16 byte model identifier, and the FIDO Metadata Service let a website or an administrator look up what a key is, how it was certified, and whether its maker has reported a problem.
• Firmware on most secure element keys cannot be updated in the field. That closes a remote attack path and leaves you replacing the key when a flaw is found, as one maker's September 2024 advisory showed.
• Register at least two keys, buy from the maker or an authorised reseller, and check model and firmware against advisories once a year.

What is inside a hardware security key?

Open a security key (most cannot be opened without destroying them, which is the point) and you find very few parts. Every extra component is something that can fail, leak or be swapped.

Two architectures dominate. In the first, a single secure element does everything: USB or NFC interface, cryptography, key storage and the FIDO application, which runs as an applet on a smart card operating system such as a Java Card platform or as native firmware in the chip. In the second, a general purpose microcontroller runs the FIDO firmware and either keeps keys in its own flash behind readout protection or hands the cryptography to a separate secure element over an internal bus. The FIDO Alliance's own example of an L3 design, which we come back to below, is closer to the second kind: a USB token on a basic CPU running a Common Criteria certified operating system, inside an enclosure that cannot be opened without the user noticing.

The touch sensor proves user presence, which CTAP keeps separate from user verification. A tap proves someone touched the key at that moment; a PIN or fingerprint proves who. CTAP 2.2 reports both as flags (up and uv), so a website can tell which checks the key performed.

How are secure elements made and evaluated?

A secure element is a smart card chip in a different package. It is made in the same wafer fabs as other chips, but its design and the sites that handle it are built to resist someone who has the chip in hand and plenty of time.

What makes a secure element different from an ordinary microcontroller

The design countermeasures fall into four groups.

1. Side channel resistance. Cryptographic code is written so that power draw, electromagnetic emission and timing do not depend on secret values. Hardware adds noise, random delays and masking of intermediate values.
2. Fault injection resistance. Sensors detect voltage glitches, clock glitches, temperature extremes and light (a decapsulated chip hit with a laser pulse). Code checks its own control flow and repeats critical comparisons.
3. Physical tamper resistance. An active shield of fine metal lines covers the top of the die; if it is cut or probed the chip notices. Buses and memories are encrypted and scrambled, so microprobing a wire yields ciphertext.
4. Life cycle control. Test modes used at the factory are permanently disabled before the chip leaves a controlled site, and the chip moves through defined states (manufactured, personalised, operational, terminated).

The FIDO Authenticator Security Requirements make the first group explicit: requirement 5.1, which applies at L2 and higher, says the vendor shall document the physical security and side channel attack protections the authenticator uses. The same document notes that a key's security strength can degrade slightly with each use if side channels leak.

Common Criteria: EAL, protection profiles and AVA_VAN

Common Criteria (ISO/IEC 15408) is the international scheme used to evaluate these chips. Three ideas matter for security keys.

• Protection profile (PP). A reusable document that says what a category of product must protect against. For chips the main one is the Security IC Platform Protection Profile with Augmentation Packages, registered by Germany's BSI as BSI-CC-PP-0084-2014. A newer profile, BSI-CC-PP-0117 for a Secure Sub-System in a System-on-Chip ("3S in SoC", version 1.5 dated 28 February 2022), covers secure blocks embedded inside larger chips. Java Card platforms have their own protection profile.
• Evaluation Assurance Level (EAL). EAL1 to EAL7 describe how much design evidence, testing and development site scrutiny the evaluation required. PP-0084 sets its minimum at EAL4 augmented with AVA_VAN.5 and ALC_DVS.2, and chips are often evaluated above that minimum, which is why chip certificates read "EAL4+", "EAL5+" or "EAL6+". The plus means extra assurance components were added on top of the level.
• AVA_VAN. The vulnerability analysis component, from AVA_VAN.1 to AVA_VAN.5. It sets how strong an attacker the lab must assume during penetration testing. AVA_VAN.5 means the product must resist an attacker with high attack potential, which for chips means a well equipped lab with weeks of time, decapsulation and laser fault injection. Smart card evaluations rate attack potential with a shared method, which the FIDO requirements cite as the attack potential guidance for smartcards, scoring factors such as elapsed time, expertise, knowledge of the design, access to samples and equipment.

Evaluations are done by licensed labs and certified by national schemes, and the certificates are published on the Common Criteria portal with the Security Target that describes exactly what was evaluated. That last part matters: a certificate covers a specific chip, a specific version of its cryptographic library and a specific configuration. A key maker who puts a certified chip in a key inherits that evidence only for what the Security Target covers.

Development sites are part of the evaluation too. The ALC (life cycle support) assurance class covers configuration management, delivery and development security, and chip evaluations include audits of the fabs, test houses and personalisation centres that touch the product. That is how Common Criteria reaches into the supply chain: a stolen wafer is much less useful if the test mode was locked at a site that was itself audited.

How FIDO maps onto Common Criteria

The FIDO Alliance does not repeat a chip evaluation. Its Companion Program lets a vendor reuse a Common Criteria or GlobalPlatform certificate for the platform underneath (for example the IC plus a Java Card operating system) and evaluate only the FIDO authenticator on top. The vendor writes a Security Target for the authenticator application, fills in a mapping table that shows which FIDO requirements the platform certificate already covers, and submits it to a FIDO accredited lab. The FIDO Alliance states plainly that applying for the higher levels without a Companion Program is not recommended.

The mapping table lists four platforms: the Security IC Platform PP (PP-0084), the 3S in SoC PP (PP-0117), the Java Card protection profile, and the GlobalPlatform TEE protection profile, which is only available at L3. The requirements document then calibrates the levels: at L3 the protection must resist enhanced basic effort attacks, assessed with AVA_VAN.3 or higher; at L3+ it must resist moderate or high effort attacks, assessed with AVA_VAN.4 or higher.

How are attestation keys and certificates injected at the factory?

Attestation is how a key proves what it is. When you register a key with a website, the key can sign the new credential's public key with an attestation private key, and include a certificate chain that leads to the maker's root certificate. The website checks the chain and learns "this credential was created inside a genuine model X key", not who you are.

What an attestation batch is

The W3C Web Authentication Level 3 Recommendation describes Basic attestation, and notes that it is also called batch attestation: the attestation key pair is specific to an authenticator model, so keys of the same or similar model often share the same attestation key pair. The reason is privacy. If every key had a unique attestation key, the attestation certificate would be a serial number that every website could see and compare.

The FIDO Authenticator Security Requirements turn this into a hard number. If a maker puts an identical attestation key into a group of authenticators, each group must contain at least 100,000 devices. If fewer than 100,000 authenticators are made in total, they must all share the same attestation key. The note under the requirement explains the goal: an authenticator must not leak a correlation handle across websites.

How the key gets in

Makers do not publish their line procedures, but the specifications and the chip evaluation model point to two broad patterns.

1. Injected batch key. The maker generates the batch attestation key pair inside a hardware security module in a controlled facility, has its batch certificate signed by an intermediate or root certificate authority, and injects the private key and certificate into each chip of that batch over an encrypted personalisation channel using transport keys agreed with the chip maker. The batch key never leaves secure hardware in plaintext.
2. On-chip generated key with a batch or per-device certificate. Some platforms generate the attestation key inside each chip and have the factory sign a certificate for it. Per device certificates conflict with the 100,000 rule for consumer keys, so this pattern is used with care, for example for enterprise attestation.

Either way, the factory also writes the model's AAGUID, a 16 byte Authenticator Attestation GUID. CTAP 2.2 places it as the first 16 bytes of the attested credential data, and the FIDO Metadata Statement for the model must carry the same value for any FIDO2 authenticator. The AAGUID identifies the model, not the unit.

The root certificate the batch chains to is published in the model's metadata statement under attestationRootCertificates, described in the FIDO Metadata Statement specification as the list of trust anchors for the batch chain. That is how a website can verify attestation for a model it has never seen.

Enterprise attestation, the deliberate exception

CTAP defines an enterprise attestation feature, signalled by the ep option in authenticatorGetInfo. An enterprise attestation can carry a unique device identifier so that an organisation can tie a specific key it bought to a specific employee. WebAuthn only lets a website request it with the enterprise conveyance value, and the browser decides whether to allow it for that website. CTAP 2.2 describes two flavours. In vendor facilitated enterprise attestation, the key maker burns a list of relying party IDs, supplied by the buying organisation, into the key at the factory, and the list cannot be updated. In platform managed enterprise attestation, an enterprise managed browser or operating system vets the relying party itself. Either way it is a factory or fleet decision, not something a website can switch on.

What does FIDO certification test, and what does FIPS 140-3 add?

FIDO certification is two programmes run in sequence.

Functional certification

Functional certification checks that the implementation conforms to the specifications and interoperates with real FIDO clients and servers. The vendor first runs the FIDO conformance self validation tools, then takes the product to an interoperability testing event or session. For L1, some security requirements are tested during interoperability testing using the L1 certification test procedures. For every other level, no security requirements are tested at this stage, but functional certification is still a prerequisite.

Authenticator security certification levels

According to the FIDO Alliance, an authenticator must be certified to at least L1 to receive UAF, U2F or FIDO2 certification, and the levels build on each other, so L2 includes all of L1 plus more.

Two details in that table are easy to miss. First, L2 explicitly excludes authenticators that do not support attestation, so a key with no attestation at all cannot reach L2. Second, the L3 page's example spells out the physical requirement: the hardware casing cannot be opened easily and any opening shall be visible to the user. That is the formal reason security keys are potted or welded rather than screwed together.

The requirements documents are versioned. On the FIDO Alliance's levels page as of October 2026, version 1.7 is active, version 1.6 remains active until a sunset date of 13 January 2027, and version 1.5.1 must still be used for L3 and L3+ and is excluded from the sunset policy. When you read a certificate, the level and the requirements version together tell you what was tested.

What FIPS 140-3 validation adds

FIPS 140-3 is the US and Canadian standard for cryptographic modules, run by NIST and the Canadian Centre for Cyber Security through the Cryptographic Module Validation Program (CMVP). NIST published FIPS 140-3 on 22 March 2019, superseding FIPS 140-2; it adopts ISO/IEC 19790:2012 and ISO/IEC 24759:2017, modified by NIST's SP 800-140 series.

Where FIDO asks "is this a good authenticator", FIPS 140-3 asks "is this cryptographic module built and tested to a federal standard". It checks the approved algorithms (with algorithm certificates from the separate validation programme), self tests at power up, key zeroisation, the module boundary, roles and services, and physical security at one of four security levels. The FIPS 140-2 text that FIPS 140-3 superseded describes the physical side clearly: Level 2 adds tamper evidence, such as coatings or seals that must be broken to reach the keys; Level 3 aims to detect and respond to physical access attempts with a high probability, for example with tamper detection circuits that zeroise secrets; Level 4 wraps the module in a complete envelope of protection that detects and responds to any unauthorised physical access.

The validation status moves on a fixed calendar. According to the CMVP page, validated modules go on the Active list for five years (or two years for interim validations). FIPS 140-2 active modules could be used for new systems until 21 September 2026, after which FIPS 140-2 certificates move to the Historical list. If your organisation buys keys for federal work, a FIPS 140-2 certificate on an older model is no longer enough for a new deployment.

NIST SP 800-63B-4, the 2025 revision of the US digital identity guidelines, ties this together for authentication. AAL3 requires a phishing resistant authenticator with a non-exportable authentication key and proof of two factors. A non-exportable authenticator must be designed so that the secret cannot be exported to the host and the host cannot reprogram it to extract the secret. The guideline adds that organisations should use authenticators that have undergone independent security testing, such as validation to FIPS 140 security level 2 overall with level 3 physical security, or evaluation against relevant Common Criteria protection profiles. We cover the levels in NIST authenticator assurance levels explained.

Why is firmware on most keys not field updatable?

Most secure element keys ship with firmware that can never be changed. When the chip is personalised, the loading interface is closed and the smart card life cycle moves the chip into a state where no new code can be installed. The maker then cannot fix a bug, and neither can anyone else.

The reasons are concrete.

• Removing the update path removes an attack path. An update mechanism is code that accepts new code. If it has a flaw, or the signing key behind it leaks, every key in the field becomes reprogrammable. A key that cannot be updated has no such door.
• Certification covers a fixed binary. A Common Criteria certificate and a FIDO L3 or L3+ certificate apply to an exact version. Field updates would need their own evaluated, secure update process, and every new version would need maintenance work on the certificate.
• Attestation means something. If firmware can change, "model X" no longer tells a relying party what code is running. The FIDO Metadata Statement specification handles this by requiring the maker to update authenticatorVersion when firmware updates fix severe security issues, and by recommending that a FIDO server assume increased risk if the authenticator reports an older version than the metadata lists.
• Version reporting still matters. CTAP defines an optional firmwareVersion field in authenticatorGetInfo and says the authenticator must increase it whenever any code change is released, so different production runs are distinguishable even when no unit can be updated.

The cost showed up on 3 September 2024, when one key maker published an advisory (CVSS 4.9, moderate) for a side channel weakness in the ECDSA implementation of its chip supplier's cryptographic library. It covered that maker's keys with firmware before 5.7.0 and said FIDO use was primarily affected. An attacker would need physical possession of the key, knowledge of the target accounts and specialised equipment, and the maker said later firmware uses its own cryptographic library instead. Because those keys cannot be updated, anyone who judged the risk relevant needed a new key. The lesson is a supply chain one: even firmware that never changes has dependencies.

Open firmware keys that can be updated

The other category runs open source firmware on a general purpose or secure microcontroller and accepts signed updates. The trade-offs are the mirror image.

Neither choice is wrong. Open firmware keys suit people who want to audit the code and patch quickly. If your threat model includes someone stealing a key and taking it to a lab, a certified secure element with no update path is stronger, at the cost of replacement when a flaw lands.

Timeline: the standards behind a security key

These dates come from the documents themselves or the pages that publish them.

Step table: from raw material to finished key

The table below is the generic flow. Individual makers split steps between chip makers, contract manufacturers and their own facilities differently and rarely publish the details, so treat it as a map of where each control sits, not as any one maker's process.

The one step people underestimate is step 7. If the personalisation room or its hardware security module were compromised, an attacker could mint attestation for keys that are not genuine. That is why makers keep the attestation root offline, why the FIDO Metadata Service has an ATTESTATION_KEY_COMPROMISE status, and why a relying party that depends on attestation should consume metadata status reports rather than a hard coded list of roots.

Comparison table: security keys, platform authenticators and synced passkeys

People compare security keys with the passkeys their phone or password manager already offers. They are all FIDO authenticators; they differ in where the key lives and what happens when you lose the device.

The privacy and policy side of that table, including whether a company should require attestation, is covered in are passkeys a trap? what attestation means and synced versus device bound passkeys.

Step by step: register two keys and check what they are

This walkthrough uses the open source libfido2 command line tools, available in most Linux distributions and on macOS through common package managers, plus the FIDO Metadata Service. None of these commands writes to the key, but fido2-token has other modes that do (reset, set PIN, delete credentials), so copy commands carefully.

1. Find the key and read its details

Plug in the first key and list FIDO devices.

# List connected FIDO devices
fido2-token -L

# Show what the key reports about itself (read only)
fido2-token -I /dev/hidraw4

On macOS the device path looks like ioreg://4294971234 rather than /dev/hidraw4; use whatever -L prints. Depending on the key and the libfido2 version, the -I output includes the CTAP versions, the AAGUID, the options the key supports (rk for discoverable credentials, clientPin, up, uv, ep), the maximum message size, the PIN retry counter and, on keys that implement CTAP 2.1 or later, the firmware version and the minimum PIN length. Write down the AAGUID and the firmware version.

Things to check in that output:

• rk is present. If it is absent, the key cannot store discoverable credentials (passkeys that work without typing a username). Older U2F only keys do not support them at all.
• clientPin is present and set. If clientPin is false, no PIN is set yet. CTAP 2.2 sets the baseline minimum PIN length at 4 Unicode code points, a maximum of 63 bytes, and no more than 8 PIN retries before the PIN is blocked, but makers can enforce stricter rules.
• Remaining discoverable credentials. Keys that report remainingDiscoverableCredentials tell you how much space is left; storage is finite and differs between models.
• Certifications. CTAP 2.2 lets a key list its certifications in authenticatorGetInfo: FIPS-CMVP-3 and FIPS-CMVP-3-PHY as levels 1 to 4, CC-EAL as 1 to 7, and FIDO as 1 to 6, where odd numbers are the plain levels and even numbers the plus levels (so L3+ reports as 6). The specification calls these hints; a relying party still has to validate attestation and the AAGUID itself.

2. Look the AAGUID up in the FIDO Metadata Service

The FIDO Metadata Service publishes a signed BLOB, a JSON Web Token, that lists every authenticator whose maker submitted a metadata statement, with its certification status and status reports.

# Download the current metadata BLOB (a signed JWT)
curl -sL https://mds3.fidoalliance.org/ -o mds.jwt

# Decode the payload (second part of the JWT) and find one AAGUID
python3 - <<'EOF'
import base64, json
token = open("mds.jwt").read().strip()
payload = token.split(".")[1]
payload += "=" * (-len(payload) % 4)
blob = json.loads(base64.urlsafe_b64decode(payload))
aaguid = "replace-with-your-aaguid"
for entry in blob["entries"]:
    if entry.get("aaguid", "").lower() == aaguid.lower():
        ms = entry["metadataStatement"]
        print(ms["description"])
        print("authenticatorVersion:", ms.get("authenticatorVersion"))
        for r in entry["statusReports"]:
            print(r.get("effectiveDate"), r.get("status"), r.get("url", ""))
EOF

This script only decodes the payload for reading. A relying party that uses the BLOB for decisions must verify the JWT signature against the FIDO Metadata Service root certificate, as the Metadata Service specification requires; do not skip that in production code.

Read the status reports from oldest to newest. FIDO_CERTIFIED_L1 through FIDO_CERTIFIED_L3plus record certification. UPDATE_AVAILABLE points to a firmware update. USER_KEY_PHYSICAL_COMPROMISE, USER_KEY_REMOTE_COMPROMISE, USER_VERIFICATION_BYPASS, ATTESTATION_KEY_COMPROMISE and REVOKED are the ones that should make you act. The Metadata Service specification notes that if the latest entry is UPDATE_AVAILABLE, the update is intended to fix all earlier reported issues.

Compare the firmwareVersion your key reported with the authenticatorVersion in the statement. The Metadata Statement specification says an authenticator with a lower version than the one in the statement is assumed to be vulnerable.

3. Register both keys on each important account

On each account that supports security keys, add the first key, then immediately add the second in the same session. Name them in the account settings so you can tell them apart later ("Key A, carried" and "Key B, safe"). Then test the second key by signing out and signing back in with it before you put it away. A backup that has never been tested is a guess.

If you run a WebAuthn server, store the AAGUID with each credential. It lets you find every credential on an affected model if an advisory lands.

4. Store the backup key

Keep the second key somewhere you can reach in a day but a burglar would not find with the first: a locked drawer at home if you carry the first, or a safe deposit box or a trusted person's home. Keep a written note of which accounts it is registered on. Our guide to offline storage for signing keys, recovery codes and security keys goes further.

5. Set a yearly check

Once a year, plug in both keys, run fido2-token -I, compare the firmware versions against the maker's security advisories and the Metadata Service status reports, and confirm both still sign in. Add a key to any account that gained security key support since last year.

Common mistakes

• Registering one key only. Lose it and you are at the mercy of the account recovery process, which is usually the weakest part of the account. Register two, every time.
• Buying from unofficial marketplace sellers. A used or relisted key may have been opened, swapped or pre-registered. Buy from the maker or an authorised reseller, check the tamper evident packaging, and reset any key that arrives with credentials on it. A reset wipes credentials but cannot prove the hardware is genuine; attestation verified against the Metadata Service can.
• Assuming every key supports passkeys and the same PIN rules. Discoverable credential support, storage capacity, minimum PIN length and biometric support differ by model and firmware. Check fido2-token -I before you plan a rollout.
• Ignoring advisories because the firmware cannot be updated. Fixed firmware does not mean fixed risk. When an advisory names your firmware range, decide whether it matters for your threat model and replace the keys if it does.
• Treating FIDO certification as one thing. A key certified functionally and at L1 is a very different product from one at L3+. Read the level, not just the logo.
• Hard coding attestation roots. Relying parties that pin a list of root certificates miss revocations and compromise reports. Consume the Metadata Service BLOB, verify its signature, and refresh it on a schedule.
• Forgetting the software around the key. The browser, the operating system's FIDO stack and the WebAuthn library in your own application decide whether the key's guarantees reach your users. Those are ordinary software dependencies with their own advisories.

Where Safeguard fits, honestly

Safeguard does not test, certify or analyse security key hardware or firmware, and it cannot tell you whether a chip resists side channels. The fit is one layer up. If your team builds a WebAuthn login, the server library that parses attestation statements and verifies signatures, the JSON Web Token library that checks the Metadata Service BLOB, and the browser side code are open source dependencies that appear in your repositories and containers. Safeguard scans those repositories, images and SBOMs, matches components against vulnerability databases, shows which projects carry a given component version, and can open a fix pull request when a patched version exists, with autonomous remediation switched off until you turn it on. That is useful when an advisory lands in the code that verifies keys, and silent on the keys themselves.

FAQ

What chip is inside a security key?

Most keys use a secure element, a smart card class chip designed to resist physical and side channel attacks and evaluated under Common Criteria. Some use a general purpose microcontroller with readout protection, sometimes paired with a separate secure element for key storage.

Can a security key be hacked?

Remotely, there is very little to attack: the key only answers signed challenges for websites whose origin matches. Physical attacks exist and are what FIDO L3 and L3+ and Common Criteria AVA_VAN levels measure. Published side channel attacks on keys have required physical possession, specialised equipment and, depending on the use case, the PIN or account password as well.

Can I update the firmware on my security key?

On most secure element keys, no. The update interface is closed at the factory. Keys built on open firmware usually accept signed updates through the maker's tool. Check fido2-token -I or the maker's app to see your firmware version.

What does FIDO certified mean?

It means the model passed FIDO functional certification (conformance and interoperability) and at least authenticator security level L1. Higher levels, up to L3+, require an accredited lab evaluation and, at L3 and above, Common Criteria evidence.

What is the difference between FIDO L2 and L3?

L2 requires an allowed restricted operating environment and attestation and protects against basic, scalable attacks. L3 adds resistance to enhanced basic hardware attacks, assessed at Common Criteria AVA_VAN.3 or higher, and requires a case that shows if it was opened.

What is an AAGUID?

An Authenticator Attestation GUID: a 16 byte identifier for a key model, included in the attested credential data at registration. It lets a website look up the model in the FIDO Metadata Service. It identifies the model, not you.

Is a security key FIPS 140-3 validated?

Only if that specific model and firmware appear on NIST's CMVP validated modules list. FIPS 140-3 and FIDO certification are separate; a key can have either, both or neither.

Why do I need two security keys?

Because a lost key cannot be recovered and has no backup copy of its credentials. The second key is your recovery method. Register both on every account at the same time.

Is a security key safer than a passkey on my phone?

Both are phishing resistant. A device bound key on certified hardware resists key extraction better and fits AAL3; a synced passkey is easier to recover. Many people use synced passkeys for everyday accounts and keys for the ones that matter most.

Can a website tell which security key I use?

If it requests attestation and you allow it, the website learns the model through the AAGUID and batch certificate, but because batches contain at least 100,000 keys, not which unit. Without attestation it learns nothing about the hardware.

A security key's firmware is fixed, but the code that talks to it is not: browsers, operating system FIDO stacks and the WebAuthn and token libraries in your own login service are open source components that receive security fixes like any other. The September 2024 advisory above also showed that even certified hardware inherits a third party cryptographic library, so the habit of tracking components and patching fast applies to every layer you do control.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval and pushes nothing. The same flow applies to a login service whose WebAuthn or JSON Web Token library has a published fix.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. When an advisory names a WebAuthn server library or a token parsing library, the same conversation can ask which of your projects carry the affected version.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• FIDO Alliance, Certification overview
• FIDO Alliance, Authenticator Certification Levels
• FIDO Alliance, Authenticator Level 1
• FIDO Alliance, Authenticator Level 1+
• FIDO Alliance, Authenticator Level 2
• FIDO Alliance, Authenticator Level 3
• FIDO Alliance, Authenticator Level 3+
• FIDO Alliance, Authenticator Certification Companion Program
• FIDO Alliance, Functional Certification
• FIDO Alliance, Authenticator Security and Privacy Requirements v1.7
• FIDO Alliance, Metadata Service
• FIDO Alliance, FIDO Metadata Service v3.1
• FIDO Alliance, FIDO Metadata Statement v3.1
• FIDO Alliance, Client to Authenticator Protocol (CTAP) 2.2
• W3C, Web Authentication Level 3
• NIST, SP 800-63B-4 Authentication and Authenticator Management
• NIST, FIPS 140-3 Security Requirements for Cryptographic Modules
• NIST, Cryptographic Module Validation Program
• Common Criteria portal, publications and CC:2022
• BSI, Security IC Platform Protection Profile with Augmentation Packages (BSI-CC-PP-0084-2014)
• Yubico, Security Advisory YSA-2024-03
• NIST, FIPS 140-2 Security Requirements for Cryptographic Modules (superseded)
• libfido2, fido2-token manual page

Last reviewed: 25 October 2026.