Are Passkeys a Trap? What Passkey Attestation Means for Your Company

No, passkeys are not a trap, but attestation is a real dial and you should know who controls it. Synced passkeys from Apple, Google and most password managers send no attestation, so a consumer site cannot tell which device you used. Enterprises can require attested, device-bound passkeys, and for admins and package maintainers they usually should.

That is the short answer to a debate that filled security forums this month. On 10 October 2026 an essay on the Non-Functional newsletter titled "Passkeys are a trap. Do not use them." argued that attestation lets websites restrict users to approved software and platforms. On 14 October Scott Helme published "Passkeys Are Not a Trap", arguing that attestation reveals far less than the essay claimed and that consumer sites have every reason not to ask for it. A lobste.rs thread on 21 October kept the argument going.

Both sides are pointing at something real. This guide covers what attestation is in the W3C WebAuthn standard, what a site actually receives today, where the lock in fear is realistic, how passkeys compare with other MFA, what NIST and PCI DSS say, and how maintainers should protect the accounts that publish code. Platform facts come from vendor documentation and standards bodies, read on 22 October 2026.

If you are new to passkeys, start with how passkeys work and why they resist phishing and passkeys vs passwords for business. This post assumes you know the basics and focuses on attestation.

Key takeaways

• Attestation is optional and off by default. In WebAuthn the relying party asks for none, indirect, direct or enterprise. The default is none, and with none the browser strips identifying attestation before the site sees it.
• Synced passkeys do not attest. Microsoft's Entra documentation states plainly that synced passkeys do not support attestation, and that iCloud Keychain and Google Password Manager are synced providers. A consumer site that demanded attestation would reject most of its own users.
• Attestation proves the authenticator's make and model, not your whole device. It is a signed statement chained to the authenticator vendor, identified by an AAGUID. It is not a remote check of your browser, extensions or operating system.
• The "approved devices only" model is real inside companies. Microsoft Entra passkey profiles, Apple's Passkey Attestation configuration for managed devices and NIST's federal guidance all let an organization require attested authenticators. That is a feature for workforce identity, not a hidden consumer trap.
• Passkeys beat TOTP, SMS and push on phishing, which CISA calls the gold standard. They do not fix weak account recovery or stolen session cookies.
• Compliance accepts them. NIST SP 800-63B-4 allows synced passkeys at AAL2 and bars them at AAL3. PCI SSC FAQ 1595 accepts FIDO2 synced passkeys as phishing resistant authentication for Requirement 8.4.2.
• Maintainers are the priority group. Package registry and source hosting accounts publish code to thousands of downstream builds. Put phishing resistant factors on those accounts first, then remove long lived publish tokens with trusted publishing.

What is passkey attestation, and when does a site actually receive it?

A passkey is a WebAuthn credential: a key pair created by an authenticator (a phone, a laptop's secure hardware, a password manager or a hardware security key) for one specific website. The site stores the public key. The private key stays with the authenticator, or with the user's sync provider, and signs a fresh challenge each time the user signs in.

Attestation is an extra, optional statement produced when the credential is created. In the W3C's words it lets the authenticator vouch for itself: the authenticator signs the new public key and some metadata with a separate attestation key that the manufacturer provisioned. The W3C's Web Authentication Level 3 specification, which became a W3C Recommendation on 25 August 2026, describes "attestation conveyance" as whether and how the client passes the attestation statement and the AAGUID to the relying party.

The AAGUID

The AAGUID (Authenticator Attestation GUID) is a 128 bit identifier for a model of authenticator. Microsoft's Entra documentation summarizes the rule from the spec: a vendor must use the same AAGUID across substantially identical keys or passkey providers, and a different one from every other product. So the AAGUID tells you "this is a particular model of hardware key" or "this is a particular password manager". It does not identify the person or the individual device.

Without attestation, the AAGUID is just a claim. Anyone writing their own authenticator software could put any value there. Microsoft's guidance says exactly this: when attestation is not enforced, Entra ID cannot vouch for any property of a passkey, not even whether it is synced, so AAGUID lists are a policy guide rather than a strict control.

The four conveyance preferences

The relying party (the website) sets attestation in its registration options. The WebAuthn Level 3 spec defines four values:

Two details from the spec matter for the debate. First, the relying party only expresses a preference; the authenticator decides which attestation type and format it can produce. Second, the spec says a relying party should fail registration when the attestation is not trustworthy, but its policy may also choose to treat it as self attestation. In other words, what happens when attestation is missing is entirely the site's decision.

What the attestation actually proves

The spec lists several attestation formats, including packed, TPM, Android Key, FIDO U2F, Apple Anonymous, compound and none. In the common "basic" model, an attestation key pair belongs to a model or production batch, so the spec notes that authenticators of the same or similar model often share the same attestation key pair. That sharing is deliberate: it lets a site check the model without being able to single out one device.

To check an attestation, a server looks up the AAGUID in a trust list. The FIDO Alliance's Metadata Service (MDS) is the standard one. FIDO describes MDS as a global registry of passkey capabilities, published as a single signed file (the MDS3 BLOB) that relying parties download, cache and verify against FIDO's root certificate. It records which authenticators are FIDO Certified and at what level, so a site can enforce a policy such as "only certified hardware keys".

What attestation does not do is just as important. Helme argues that attestation identifies the authenticator's make and model through a vendor certificate chain, and does not report your operating system, browser, extensions or jailbreak status. The essay counters that attestation depends on the chip, passkey manager, operating system and firmware all passing a check, so a custom OS could fail. For a hardware key, attestation is about the key alone. For a platform authenticator, the vendor's software produces the statement, so a modified platform may not be able to. Both readings are partly right, which is why what sites actually receive matters more than the theory.

Synced versus device-bound passkeys: what is the security difference?

The FIDO Alliance says passkeys "can be securely synced across a user's devices, or bound to a particular device." The difference is where the private key can live.

Device-bound passkeys are created and kept on one authenticator. Microsoft defines them as keys that never leave a single physical device, with examples such as hardware security keys and Microsoft Authenticator. FIDO says device-bound passkeys on hardware security keys offer the highest security assurance.

Synced passkeys are encrypted and copied to a cloud provider so that every device signed in to that provider can use them. Apple says iCloud Keychain is end to end encrypted with keys not known to Apple, and that the escrow used for recovery is protected against brute force, including by Apple. Microsoft's definition adds the line that matters most for this debate: "Synced passkeys do not support attestation."

The WebAuthn spec gives relying parties a way to tell the two apart without attestation, at least as a claim. The authenticator data carries two flags:

• BE (Backup Eligible) is set when the credential is created and never changes. The spec calls backup eligible credentials multi-device credentials, and the rest single-device credentials.
• BS (Backup State) says whether a multi-device credential is currently backed up. It can change over time.

Without attestation these flags are self reported, just like the AAGUID. With attestation from a trusted authenticator, they are as trustworthy as the authenticator.

The honest summary: both kinds stop phishing. The difference is that a synced passkey's strength now also depends on the cloud account that holds it. If an attacker can take over that account, for example through a weak recovery path, they may be able to sync the passkeys to a device they control. A device-bound key moves that risk to physical theft plus the key's PIN.

Is the lock-in or "approved devices only" fear realistic?

For consumer sites

The essay's core worry is that attestation gives sites a "hidden dial" they could slowly turn, first rejecting unusual passkey managers, then alternative operating systems and browsers. It is a fair thing to watch for. The technical facts available today point the other way for consumer services.

• The default preference is none, and the browser actively strips attestation when a site does not ask.
• The largest passkey providers do not attest synced passkeys. Microsoft's documentation lists Apple iCloud Keychain and Google Password Manager as synced providers and states that synced passkeys do not support attestation. Helme reports that sites receive none from those and from third party password managers.
• Google's own server registration guide for passkeys sets the attestation type to none in its example code and describes attestation as "a more advanced technique to verify a passkey provider's identity."

So a consumer site that required attestation would lock out the majority of its passkey users on day one. Helme's rebuttal makes that argument and also concedes the important point: if attestation ever does creep into consumer logins, people should push back loudly. That is a reasonable position for anyone, and it costs nothing to keep an eye on.

Where the essay has a stronger case is portability. A passkey in one provider's sync fabric is only as portable as that provider allows. The FIDO Alliance is working on this through its credential exchange specifications, which define a standard, encrypted format for moving passwords and passkeys between providers. The Credential Exchange Protocol draft we read is a working draft dated 3 October 2024 that says it should not yet be a basis for implementations; a later Credential Exchange Format document carries a March 2026 date. Check your provider's current import and export support before you assume you can move.

For enterprises

Inside a company the "approved devices only" model is real, intentional and documented. That is the point of enterprise attestation.

• Microsoft Entra ID passkey profiles let an administrator set "Enforce attestation", allowed passkey types (device-bound, synced) and AAGUID allow or block lists per group. Microsoft's own example profile puts IT admins, executives and engineering on device-bound passkeys with attestation enforced, while HR and sales may use synced passkeys. When attestation is enforced, only device-bound passkeys are possible.
• Apple has a Passkey Attestation declarative configuration (iOS 17, iPadOS 17 and macOS 14 and later) that lets an organization verify a passkey was created on a managed device. It only applies to relying party domains the organization lists in the configuration.
• NIST SP 800-63B-4 says federal enterprise verifiers should use attestation to verify authenticator capabilities and sources, and that other applications may use it in risk based decisions.

This is not a trap for employees any more than a corporate laptop policy is. The company owns the accounts and the risk. The real concern would be a consumer service treating its customers like employees, and nothing in the current platform behavior makes that easy.

Where the debate lands

Are passkeys safer than TOTP, SMS and push MFA?

On phishing, yes, and this is the part of the debate where both sides agree. The essay itself concedes passkeys resist man in the middle attacks.

CISA's fact sheet "Implementing Phishing-Resistant MFA" (October 2022) ranks MFA forms from strongest to weakest. FIDO/WebAuthn and PKI based MFA sit at the top as the "gold standard". App based OTP and push with number matching come next and are vulnerable to phishing. Push without number matching is vulnerable to push bombing. SMS and voice are a last resort, vulnerable to phishing, SS7 attacks and SIM swaps. CISA also says the only widely available phishing resistant authentication is FIDO/WebAuthn.

NIST SP 800-63B-4 explains why. It defines phishing resistance as the protocol preventing disclosure of authentication secrets to an impostor verifier without relying on the user's vigilance. Codes that a person types into a page, whether from an app, a hardware token or a text message, fail that test because nothing binds the code to the real site. WebAuthn binds the signature to the site's origin, so a lookalike domain gets nothing useful.

Where passkeys still fail

Passkeys protect the moment of sign in. They do not protect everything around it.

Account recovery. If a user can lose their passkey and get back in with an email link, an SMS code or a help desk call, an attacker can try the same path. The account is only as strong as its weakest way in. Apple's own iCloud Keychain recovery requires the account password, an SMS response and a device passcode, with a limit of 10 attempts before the escrow record is destroyed, which shows how much engineering a provider puts into this layer. Your own application's recovery flow needs the same attention.

Session theft. Once the user signs in, the site issues a session cookie or token. Malware on the endpoint that copies that cookie can reuse the session without ever touching the passkey. Short session lifetimes, re-authentication for sensitive actions and binding sessions to the device where your platform supports it all help. Passkeys alone do not.

Fallback factors. If an account allows a passkey or TOTP or SMS, an attacker picks the weakest. For high value accounts, remove phishable fallbacks once every user has two passkeys.

Registration. A passkey registered by an attacker who already controls the account is a perfectly valid passkey. Require a recent strong authentication before anyone adds a new credential. Microsoft, for example, requires users to have completed MFA in the past five minutes before they can register a passkey.

Should an enterprise require attestation, and for which roles?

Yes for a small set of roles, no for everyone by default. Attestation adds cost: a trust list to maintain, hardware to buy and ship, more help desk work and a worse recovery story. It pays for itself where one stolen login can do outsized damage.

Require attested, device-bound passkeys (usually hardware security keys) for:

• Identity and cloud administrators. CISA singles out system administrators as the first group for phishing resistant MFA, and notes attackers target identity servers to create or take over accounts.
• Package maintainers and release engineers who can publish to npm, PyPI, Maven Central, container registries or internal artifact stores.
• Source control organization owners and anyone who can change branch protection, Actions secrets or deploy keys.
• CI and CD administrators who can edit pipelines or signing keys.
• Break glass accounts.
• Executives and finance approvers who are frequent targets of social engineering.

Allow synced passkeys, without attestation, for most other employees. A synced passkey is still phishing resistant, and Microsoft's guidance is to treat synced passkeys as phishing resistant credentials with the same posture as other unattested authenticators. That is a large step up from passwords and OTP.

A practical policy:

Two rules from Microsoft's documentation catch teams out. Attestation is checked only at registration, so turning on enforcement later does not block passkeys already registered without it. And removing an AAGUID from an allow list immediately stops those users from signing in with that authenticator. Plan a re-registration campaign when you tighten policy, and stage AAGUID changes.

Do passkeys satisfy NIST AAL2, SOC 2, ISO 27001 and PCI DSS MFA requirements?

NIST SP 800-63B-4

NIST's current digital identity guidelines treat synced passkeys explicitly as "syncable authenticators" in a normative appendix.

• AAL2: yes, with conditions. The appendix walks through why synced passkeys can meet AAL2: phishing resistance through domain binding, replay resistance through a random challenge, authentication intent through a user action, and multi-factor status through the User Verified (UV) flag. Verifiers shall request UV and, if it is not set, treat the passkey as a single factor.
• Sync fabric requirements. Keys exported to a sync fabric must be encrypted with at least 112 bits of security strength, private key operations must happen on the local device, and access to the sync fabric itself must require AAL2 equivalent multi-factor authentication.
• AAL3: no. AAL3 needs a non-exportable private key, and NIST states that syncable authenticators shall not be used at AAL3. Device-bound passkeys on suitable hardware can meet AAL3.
• Attestation. Federal agencies should implement attestation where platforms support it, but its absence should not block broad public facing use.
• BE and BS flags. Verifiers may use them to restrict syncable or synced authenticators, but for public facing applications NIST says agencies should not base acceptance on the backup state, because of user experience concerns.
• Federal enterprise additions. Managed devices to stop syncing to unauthorized devices, sync through agency managed accounts, and support for attestation such as enterprise attestation.

PCI DSS v4

The PCI Security Standards Council answered this directly in FAQ 1595 (May 2025). Synced passkeys implemented according to FIDO2 requirements are considered phishing resistant authentication and may be used as a single factor in place of MFA to meet Requirement 8.4.2, consistent with that requirement's applicability note. Passkeys not implemented to FIDO2 requirements need an additional factor to meet Requirements 8.4.1, 8.4.2 and 8.4.3. A companion FAQ, 1596, covers whether phishing resistant authentication alone is acceptable for 8.4.1 and 8.4.3; read it with your assessor before you rely on a passkey alone for administrative or remote access into the cardholder data environment.

SOC 2 and ISO 27001

Neither framework names passkeys or a specific MFA method. ISO/IEC 27001:2022 Annex A control 8.5, "Secure authentication", asks for secure authentication procedures in line with your access control policy. SOC 2's logical access criteria ask you to design and operate access controls that fit your risks. In both cases the auditor tests what your own policy says and whether you follow it.

A passkey policy is easy to defend because it is phishing resistant by design, but it does not rescue a control with undocumented exceptions. Expect auditors to ask for the authentication policy, the identity provider configuration showing allowed methods per group, users and their registered methods, approved exceptions, and recovery procedures.

How should developers and package maintainers protect registry and GitHub accounts with passkeys?

This is where passkeys meet the software supply chain. A maintainer's registry account can publish a new version that thousands of build systems pull within hours. Registry account takeover through phished credentials and stolen tokens has been behind several of the worst open source incidents, which we covered in the Shai-Hulud npm supply chain attack explained. Phishing resistant sign in removes one of the two main ways in. Removing long lived publish tokens removes the other.

What the platforms support today

• GitHub lets passkeys satisfy both the password and 2FA requirement in one step, and they can be used for sudo mode and password resets. GitHub requires 2FA for accounts that publish apps or actions, create releases, contribute to high importance repositories, own organizations or administer repositories that publish packages. Note one nuance in GitHub's mandatory 2FA page: it recommends a TOTP app as the primary 2FA method and passkeys or security keys as backups, because they are easy to lose and do not sync across enough devices. That is about account lockout, not phishing. For maintainers, register at least two passkeys or hardware keys so loss is not a lockout.
• npm supports WebAuthn security keys and built in biometrics for 2FA. By default 2FA covers both sign in and writes. Publishing requires 2FA or a granular token with bypass 2FA enabled, and npm says that from August 2026 account identity and governance actions cannot be done with a bypass 2FA token.
• PyPI requires 2FA on every account and supports security devices (WebAuthn) and TOTP apps. It recommends at least two methods plus recovery codes.

Step by step: lock down a maintainer account

1. Register two phishing resistant factors on each account. On GitHub, go to Settings, then Password and authentication, then Passkeys, and add one passkey from your platform and one hardware security key kept somewhere else. On npm, add a security key under Account, then Two-Factor Authentication. On PyPI, add a security device under Account settings and generate recovery codes. Store recovery codes offline.

2. Turn on 2FA for both sign in and writes on npm.

# Requires 2FA for login and for publish and other write actions
npm profile enable-2fa auth-and-writes

# Confirm the current setting
npm profile get

3. Require 2FA for everyone in your GitHub organization and find stragglers.

# Is 2FA required for the organization? (needs org owner access)
gh api orgs/YOUR_ORG --jq '.two_factor_requirement_enabled'

# List members who have not enabled 2FA
gh api "orgs/YOUR_ORG/members?filter=2fa_disabled" --paginate --jq '.[].login'

Requiring 2FA in an organization removes members who do not have it, so run the second command and contact those people first.

4. Replace publish tokens with trusted publishing. npm's trusted publishing uses OpenID Connect from GitHub Actions, GitLab CI/CD on GitLab.com shared runners or CircleCI cloud, so no long lived npm token sits in CI. It needs npm CLI 11.5.1 or later and Node 22.14.0 or later, and it generates provenance attestations automatically for public packages from public repositories on GitHub Actions and GitLab.

# .github/workflows/release.yml
name: release
on:
  release:
    types: [published]

permissions:
  contents: read
  id-token: write   # lets GitHub mint the OIDC token npm trusts

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          registry-url: 'https://registry.npmjs.org'
      - run: npm install -g npm@latest
      - run: npm ci
      - run: npm test
      - run: npm publish

Then configure the trusted publisher on the package's settings page on npmjs.com, and under Publishing access choose "Require two-factor authentication and disallow tokens". npm's docs say trusted publishers keep working after that because they use OIDC tokens, not npm tokens.

For PyPI, the equivalent is a trusted publisher configured on the project plus the official publish action:

jobs:
  pypi-publish:
    runs-on: ubuntu-latest
    environment: pypi
    permissions:
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - run: python -m pip install build && python -m build
      - uses: pypa/gh-action-pypi-publish@release/v1

PyPI says trusted publishing is strongly recommended over API tokens wherever your CI provider supports it.

5. Revoke what is left. List and revoke old tokens (npm token list and npm token revoke <id> on npm, the API tokens page on PyPI, fine grained and classic tokens on GitHub). A phishing resistant login does nothing for a token that already sits in a laptop's dotfiles.

6. Protect the release path, not only the login. Require reviews on the release branch, restrict who can create releases, and use a protected environment with required reviewers for the publish job, so one compromised account cannot ship alone.

For teams building passkey login into a product

If you are the relying party, the defaults are your friend.

// Browser: create a passkey with no attestation request
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,            // random bytes from your server
    rp: { id: 'example.com', name: 'Example' },
    user: { id: userHandle, name: 'ana@example.com', displayName: 'Ana' },
    pubKeyCredParams: [
      { type: 'public-key', alg: -7 },     // ES256
      { type: 'public-key', alg: -257 }    // RS256
    ],
    authenticatorSelection: {
      residentKey: 'required',
      userVerification: 'required'
    },
    attestation: 'none'                    // the default; say it explicitly
  }
});

On the server, use a maintained WebAuthn library rather than parsing CBOR and certificate chains yourself, verify the challenge, origin and RP ID, check that User Present and User Verified are set, and store the AAGUID and the BE and BS flags with the credential. Google's passkey server guide recommends storing the AAGUID to show users a friendly provider name and storing the backup state so you can later decide whether a user with backed up passkeys can drop their password.

If you want to see the raw flags, the authenticator data layout is fixed by the spec: 32 bytes of RP ID hash, one flags byte, a four byte signature counter, then (at registration) the 16 byte AAGUID.

# Decode WebAuthn authenticator data flags (for inspection and logging only)
def parse_auth_data(auth_data: bytes):
    flags = auth_data[32]
    info = {
        "user_present":     bool(flags & 0x01),
        "user_verified":    bool(flags & 0x04),
        "backup_eligible":  bool(flags & 0x08),  # BE, multi-device credential
        "backup_state":     bool(flags & 0x10),  # BS, currently backed up
        "attested_data":    bool(flags & 0x40),
        "extensions":       bool(flags & 0x80),
        "sign_count": int.from_bytes(auth_data[33:37], "big"),
    }
    if info["attested_data"]:
        info["aaguid"] = auth_data[37:53].hex()
    return info

Use these values to inform policy and user interface, not as proof. Without a verified attestation they are what the authenticator chose to report.

For a workforce application where you do want attestation, request direct or enterprise, verify the statement against the FIDO Metadata Service, and fail registration when it does not verify. Request it only for the relying party IDs and user groups that need it.

Common mistakes

• Requiring attestation on a consumer product. It rejects synced passkeys from the major providers and drives users back to passwords. If you need risk signals, use them for step up checks, not for rejecting registration.
• Treating an AAGUID allow list as a control without attestation. Microsoft says plainly that without enforced attestation it cannot guarantee any attribute of a passkey.
• Turning on attestation enforcement and assuming old passkeys are covered. In Entra, attestation is checked at registration only. Re-register privileged users after you tighten policy.
• Leaving SMS or email recovery on accounts that now use passkeys. The attacker uses the weakest path. Fix recovery before you announce the passkey rollout.
• Giving maintainers one passkey. One lost phone becomes a lockout and an emergency recovery request, which is exactly the moment social engineering works best. Two factors, kept apart.
• Protecting the login and ignoring tokens. Long lived registry and CI tokens bypass every sign in control. Move to trusted publishing and revoke the rest.
• Rolling your own WebAuthn parsing. Attestation verification involves CBOR, COSE keys and X.509 chains. Use a maintained library and keep it patched, which is the subject of the next section.

Fix it without waiting for upstream

Passkey support in your product almost certainly rests on an open source WebAuthn library, plus the CBOR, COSE, JOSE and X.509 parsing code underneath it. Those libraries are dependencies like any other, and a bug in signature, origin or certificate chain checking is a bug in your login. When one of them needs a fix, the same rules apply.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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.

Where Safeguard fits, and where it does not

Safeguard does not issue passkeys, verify attestation for your users or replace your identity provider. It covers the layers around them. Dependency scanning of repositories, container images and SBOM files shows which projects carry which version of your WebAuthn, CBOR and certificate libraries, with reachability analysis. The compliance suite maps controls to frameworks such as SOC 2 and ISO 27001 and collects evidence through connectors, including identity providers; ask which identity connectors are live for your stack. Safeguard's own sign in supports SSO and WebAuthn, passkeys, FIDO2 and TOTP for two step verification.

See how Safeguard would help

These are real product sessions. None of them is a passkey demo; they show the parts of the workflow around passkeys that Safeguard touches: patching the libraries your login depends on, scanning on your own machine, and scoping what an AI assistant can reach.

This is a real Safeguard CLI session. You run safeguard, ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow applies when the vulnerable package is the WebAuthn server library or certificate parser behind your passkey login.

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

This demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. It is a quick way to see which of your services carry which version of an identity or crypto dependency.

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

This demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is the same principle as an attestation policy for admins: decide up front exactly what a trusted client may do, rather than trusting whatever shows up.

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

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

FAQ

Are passkeys a trap?

No. Attestation lets a site ask which authenticator model created a passkey, but synced passkeys from the major providers do not send attestation, and the WebAuthn default is to strip it. The "approved devices only" model exists for enterprise identity, where companies use it deliberately for privileged staff. Keep watching consumer sites, but today the trap is not sprung.

What is passkey attestation in simple terms?

A signed statement from the authenticator saying "I am this make and model", chained to the manufacturer's certificate. A site can check it against the FIDO Metadata Service. It is optional, set by the site, and usually not requested by consumer services.

Can a website see which device or password manager I use for my passkey?

It may see an AAGUID that names the passkey provider or key model, which sites use to label your passkeys. Without attestation that value is unverified. Attestation, when present, proves the model, not your individual device, browser or operating system.

Do Apple and Google passkeys support attestation?

Synced passkeys in iCloud Keychain and Google Password Manager do not provide attestation, according to Microsoft's Entra documentation and Helme's testing. Apple offers a separate Passkey Attestation configuration for managed devices on iOS 17, iPadOS 17 and macOS 14 and later, limited to domains the organization lists.

Are synced passkeys less secure than hardware keys?

Both resist phishing. Synced passkeys add a dependency on the security of the cloud account and its recovery process, and NIST bars them from AAL3 because the key is exportable. Hardware keys are stronger for administrators and maintainers; synced passkeys are a large improvement for everyone else.

Do passkeys count as MFA for PCI DSS?

PCI SSC FAQ 1595 says FIDO2 synced passkeys are phishing resistant authentication and can be used as a single factor in place of MFA for Requirement 8.4.2. For 8.4.1 and 8.4.3, read FAQ 1596 and confirm with your assessor.

Can I move my passkeys from one provider to another?

Sometimes. The FIDO Alliance is standardizing encrypted credential exchange between providers, but support depends on your provider. Before committing, check whether your provider can import and export passkeys, and keep a second passkey or hardware key registered on critical accounts.

Should open source maintainers use passkeys?

Yes, on GitHub, npm, PyPI and any registry that supports them, with at least two registered factors. Then move publishing to trusted publishing so no long lived token can be stolen, and revoke old tokens.

Quick check

Sources

• W3C, Web Authentication: An API for accessing Public Key Credentials Level 3
• FIDO Alliance, Passkeys
• FIDO Alliance, Metadata Service
• FIDO Alliance, Credential Exchange Protocol, working draft 3 October 2024
• NIST, SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management
• CISA, Implementing Phishing-Resistant MFA fact sheet
• PCI Security Standards Council, FAQ 1595 on synced passkeys and Requirement 8.4.2
• Microsoft Learn, How to enable passkeys (FIDO2) in Microsoft Entra ID
• Apple Support, About the security of passkeys
• Apple Platform Deployment, Passkey Attestation declarative configuration
• Google for Developers, Server-side passkey registration
• GitHub Docs, About passkeys
• GitHub Docs, About mandatory two-factor authentication
• npm Docs, About two-factor authentication
• npm Docs, Trusted publishing for npm packages
• PyPI, Help
• Non-Functional, Passkeys are a trap. Do not use them. (10 October 2026)
• Scott Helme, Passkeys Are Not a Trap (14 October 2026)

Last reviewed: 22 October 2026. Platform passkey and attestation behavior changes often; check the linked vendor documentation before you set policy.