The Password Replacement and Why Your Agent Needs One Too

The password is over. Not in the marketing sense — in the the U.S. federal government has mandated its replacement sense. OMB M-22-09 told civilian agencies to deploy phishing-resistant MFA by the end of fiscal year 2024. Every major IdP — Entra, Okta, Google — now ships passkey-first sign-in. Apple, Google, and Microsoft all default new accounts to passkeys when they can.

This is the largest authentication change of my career. And I think most people in security still haven't internalized it.

What's actually new

The thing that makes a passkey different from every other "MFA" is one property: origin binding. The signed assertion the authenticator produces is bound to the domain the browser is talking to. A reverse-proxy phishing kit at login-examp1e.com will produce a signature for that domain, which the real login.example.com rejects.

That's the whole trick. There is no shared secret to steal, no OTP to forward, no push fatigue to exploit. The signature is wrong, full stop.

If you've never seen the WebAuthn ceremony up close, register a passkey on the lab — the whole flow runs in 10 seconds and you can watch the credential ID and public key come back from the browser.

The headline number from the rollout has been: zero successful at-scale phishing of FIDO2 passkeys in the wild. Not "fewer." Not "harder." None. The infosec community has been chasing that property for twenty years.

The deployment trap

What we saw at every enterprise I've worked with is the same gradient:

Passkey + password fallback. Easy to deploy, but the password is still phishable. Most consumer rollouts started here.
Passwordless primary, recovery via secondary device. Real reduction in attack surface, harder helpdesk story.
Phishing-resistant only, no exceptions. AAL3 / OMB M-22-09. No SMS recovery, no "lost device, just call us" path.

Most organizations stop at step 1 and call it done. Then an attacker calls the helpdesk, says they lost their device, and walks out with a freshly enrolled passkey on their attacker phone. That was the MGM and Caesars pattern in 2023.

The control isn't the technology. It's removing the soft-fallback paths that defeat the technology.

And then there's your agent

Here's where almost every security program I see today has a blind spot.

You've spent eighteen months convincing your CFO to fund passkey rollout. Phishing is finally a controlled risk. Then your eng team ships an AI agent with an OpenAI API key in a config file, a long-lived GitHub PAT for code review, and a Stripe live key for payment automation, all sitting in the same container.

What did you actually achieve?

The agent is now the weakest credential in your environment. Steal the container, get keys to everything. The audit log says "user did X" when the agent did X. Your beautiful passkey rollout protects the front door of a house with all the windows wide open.

The fix isn't hard, but it isn't free either.

A clean model for agent identity

The same primitives that make passkeys unphishable extend to workloads:

Origin binding for humans → workload attestation for agents. The agent doesn't say it's running on a trusted node, it proves it via TPM quote, AWS Nitro attestation, or platform OIDC.
No shared secrets for humans → federated short-lived tokens for agents. GitHub Actions, AWS, Azure, and GCP all issue OIDC tokens to running workloads that the relying party verifies against a JWKS. No long-lived API key in the container. (Paste one of those tokens into the JWT inspector and watch what it flags.)
Hardware-bound for humans → non-extractable workload keys for agents. SPIFFE/SPIRE issues short-lived X.509 SVIDs to attested workloads with stable identifiers like spiffe://prod/agent/code-reviewer/v3.

And then the piece that almost nobody is wiring up yet:

Token-bound delegation. OAuth 2.0 Token Exchange (RFC 8693) lets a user's passkey-issued session token be downgraded into a narrower agent token. Scope limited to read:repo write:issues. Audience limited to github.com. TTL limited to 5 minutes. An act claim that says "the agent acting on behalf of the user." The audit log finally has a story.

I wrote a deeper piece on the agent-identity model — workload attestation, SPIFFE/SPIRE, the broken patterns most agent platforms ship today — over on the lab: Agent identity, properly.

If you want to play with the rest of it, Identity Lab walks through the WebAuthn ceremony, the JWT failure modes, and phishing-resistant MFA archetypes, with working code. It's the lab I wish I'd had ten years ago.

What to actually do

If you operate an enterprise:

Get to passkey-only for admin and break-glass accounts. No fallback.
Audit your helpdesk recovery flow. If a phone call can re-enroll a passkey, it's not phishing-resistant.
Inventory every agent and every long-lived secret it holds. There are more of both than you think.
Pilot federated workload identity for one critical agent path. The platforms are ready; most teams just haven't wired it up.

If you build agents:

Stop putting long-lived keys in config files. Use OIDC federation against your platform.
Identify the agent in your audit logs separately from the user it acts for.
Bound scope per task. The agent doing code review doesn't need repo:write.
Plan for revocation that doesn't require the user to rotate their passkey.

The same identity primitives that finally killed passwords for humans are how we keep agents from re-creating the problem at machine scale. We have the building blocks. The next two years are going to be about whether the industry actually uses them — or just slaps a passkey on the front door and calls it zero trust.

I know which side I'm betting on.