For seventeen years the working assumption underneath almost everything I have built was simple: if you hold the right credential, you are the right person. Type the password, pass the second factor, present the certificate, and the system trusts you for the rest of the session. In 2026 that assumption finally, publicly died. Roughly sixteen billion stolen credentials surfaced in a single compilation, and the attacks that matter no longer bother with passwords at all. They steal the live session and walk straight past multi-factor authentication. Possession stopped proving identity. The replacement is continuous verification: identity as something you keep proving, not a gate you clear once.
This is not a doom piece, and it is not a sales pitch for a product. It is the clearest pattern I see across both halves of my work, network security and AI systems, and it changes how you should design for trust. The good news is that the fix is already shipping. The harder news is that most teams are still defending the gate while the attacker is already inside the room.
This is not another bypass story
I have written before about authentication being bypassed through a flaw, a VPN zero-day or a framework bug that lets an attacker skip the check entirely. That is a real and recurring problem, but it is not what this is about. The session-theft wave of 2026 needs no flaw. The login succeeds. The second factor is satisfied. The credential is genuinely valid. It is simply being presented by the wrong party, because they lifted the session token after the fact.
That distinction matters because it breaks the mental model most of us were trained on. We learned to ask whether authentication could be defeated. The new question is whether a perfectly successful authentication still means anything ten minutes later, when the cookie that proves it is sitting in an infostealer log alongside a billion others. When the credential is valid and the holder is hostile, every control that fires only at login is already too late.
Possession stopped meaning identity
The whole edifice of enterprise access rested on a quiet equation: possession equals identity. Hold the badge, you are the employee. Hold the token, you are the service. It was always a convenient fiction, but it held because stealing the credential was hard enough to be the exception. Infostealers, adversary-in-the-middle phishing, and the sheer volume of leaked session material turned the exception into the baseline.
Once the session token is the unit of theft, multi-factor authentication protects the one moment the attacker does not need. They are not trying to log in; they already have the artifact that proves a login happened. I have watched teams respond to a credential scare by rolling out yet more MFA, hardening a door the attacker is no longer using. It is the security equivalent of fitting a stronger lock after the burglar has copied the key and is already drinking your coffee.
The shift is easiest to read as a before and after:
| The old model | Continuous verification |
|---|---|
| Prove identity once, at login | Re-prove possession throughout the session |
| Holding the credential equals being the person | The credential is bound to a device and a behaviour |
| MFA satisfied, trust granted for hours or days | Tokens live minutes and reach one job |
| Watch for failed logins | Watch the live session for abnormal use |
| A stolen credential is a master key | A stolen credential expires and reaches little |
It fails the same way at the firewall and the AI agent
What makes this the defining pattern of my year is that it shows up identically on both sides of my work. On the network side, a stolen VPN or management-console session is a valid cookie an infostealer read off an administrator's laptop; the appliance greets the thief as the admin. On the AI side, an agent authenticates to email, repositories, and cloud with long-lived tokens, and those tokens are now stolen straight from disk and config files. A stolen VPN session and a hijacked agent token are the same failure one layer apart: a valid credential, no longer attached to the entity that earned it.
I have made the cross-domain case in detail elsewhere, in how a firewall CVE and an AI-agent breach are the same mistake and in two auth bypasses sharing one bug. The credential-death thesis sits underneath both: it is not that two specific incidents rhymed, it is that the artifact we trust to mean identity has stopped meaning it, everywhere at once. The agent makes it worse, because an agent is a non-human identity that holds many credentials, runs unattended, and is watched by nobody at three in the morning.
Continuous verification is the replacement
If a single proof at the door is no longer enough, the answer is to keep asking quietly throughout the session. That is continuous verification, and unlike a lot of security theatre it is concrete and already deployed. Three parts of it are real today.
- Bind the session to the device. Google's Device Bound Session Credentials, generally available in Chrome on Windows since 2026, tie a session to a non-exportable key in the machine's secure hardware and re-prove possession every few minutes. A stolen cookie becomes useless on another machine because it cannot produce the signature. It is the clearest production example of identity being re-checked continuously rather than once.
- Shrink and scope the credential. A token that lives for minutes and reaches one system is a far smaller prize than one that lives for months and reaches everything. Short lifetimes and tight scope turn a stolen credential from a master key into a single, expiring door.
- Watch the session, not the login. The hijack never shows up as a failed login, because nothing failed. It shows up in use: a session active from a new network, at an odd hour, doing something the legitimate holder never does. Behavioural monitoring on the live session is where you actually catch it, and where step-up checks belong.
None of this is exotic. It is the same defence-in-depth discipline I have applied across two hundred-plus enterprise audits and a dataset of two hundred and eighty firewall migrations, pointed at a new question: not "did you authenticate" but "are you still who you were a minute ago". The honest part is that device binding mostly rescues interactive browser sessions. The headless, machine-to-machine credentials that AI agents and service accounts use are harder, which is exactly why short lifetimes, tight scope, and session monitoring carry more of the load there.
What this means if you run security
The practical shift is to stop treating authentication as a finished task once MFA is on. It is the start of a session you now have to keep verifying. Pull every system that issues a long-lived credential and ask how long a stolen token would stay valid, how much it would reach, and whether anything would notice it being used from the wrong place. For most organisations the answers today are months, far too much, and no.
This is also where governance earns its keep. The controls you add under pressure when a credential scare hits, tighter token lifetimes, revoked sessions, new egress rules, are exactly the ones a regulator or an insurer will later ask you to justify, so they need to be scoped, logged, and reversible, the same discipline I argue for in a 90-day zero-trust plan. Trust that is continuously verified is also trust that is continuously auditable, and that turns out to be the same property.
I came up through firewalls and network security, and I now spend most of my time on AI systems. The thread that connects them is this one. The credential as a standalone proof of identity is finished, killed not by a clever exploit but by its own success and the volume of theft that success invited. What replaces it is humble and continuous: prove it on the device, keep it short, and keep watching. The teams that internalise that in 2026 will spend next year containing incidents. The teams still buffing the front door will spend it explaining one.
If you are rethinking identity and session security across your network and AI stack, request a review. I run security engineering engagements anchored in 17+ years of enterprise cybersecurity. For the firewall change-management side of this, see FwChange.com.