The data backs that up. Verizon’s 2025 Data Breach Investigations Report found that stolen credentials were the most common way attackers got in for the second year running, at 22% of breaches, and that 88% of attacks on basic web applications involved stolen credentials. Attackers aren’t breaking in. They’re logging in.

Identity security isn’t wrong. It’s incomplete. Here’s why it leaves companies exposed, and why the gap is about to get much wider.

Identity is one factor. An access decision needs more.

Identity answers one question: who is this? A sound access decision has to answer several more. Is this the device we expect? Is that device healthy? Does the location make sense? Is the behavior consistent with this person, or with a person at all? Should this session still be trusted ten minutes from now?

An example of how this plays out is Microsoft 365, Microsoft’s cloud suite for email, file storage (OneDrive and SharePoint) and collaboration (Teams). Sign-in is handled by Microsoft Entra ID, Microsoft’s identity service. When a user signs in, Entra confirms who they are, and from that point the user, or whoever holds the user’s session, can reach their mail, files and chats. Entra can add device and location rules, but only for the applications it fronts. The file server in the data center, the remote desktop host, the client-server ERP application and the operational technology (OT) network all sit outside that decision.

When identity is treated as the whole answer, the “who” becomes the only thing standing between an attacker and your data. Steal or spoof the who, and everything else follows.

MFA helps. But steal the token and you’re home free.

MFA is one of the most valuable controls a company can turn on, and nothing here argues against it. But MFA protects the moment of login. It does not protect what happens after.

When you sign in, the identity provider gives your browser a session token, a digital pass that says “this user has already proved who they are.” For hours, sometimes days, every request carries that pass instead of asking you to sign in again. The token is a bearer credential: whoever holds it can use it.

That is precisely what attackers go after. In an adversary-in-the-middle (AiTM) attack, a phishing site sits between the user and the real login page. It passes everything through, including the MFA prompt, and quietly copies the session token the moment the login succeeds. The user did everything right. The attacker walks in with a valid pass. A newer variant, device code phishing, skips the fake page entirely: the victim is tricked into entering a code on Microsoft’s genuine sign-in page, completes MFA themselves, and unknowingly hands the resulting tokens to the attacker. Infostealer malware does the same thing from the device side, lifting session cookies straight out of the browser. SpyCloud recaptured 8.6 billion stolen session cookies circulating in underground sources in 2025 alone.

This isn’t theoretical, and 2026 has made the point repeatedly:

• April: Microsoft reported an AiTM campaign that, over just three days, targeted more than 35,000 users at over 13,000 organizations in 26 countries, built to capture authentication tokens that give immediate account access.
• July to September: Huntress tracked attackers replaying stolen Microsoft 365 sessions at 79 organizations, with at least 497 successful sign-ins. In 19 of those organizations, the attackers wiped the victim’s MFA methods and registered their own within three hours of getting in.
• September: Microsoft and its partners took down EvilTokens, a device code phishing service that had compromised more than 12,000 inboxes across over 10,000 organizations. Victims never gave up their passwords. Microsoft noted that access could persist even after a password reset if the sessions and tokens weren’t also revoked.

It isn’t only user sessions. In August 2025, attackers used OAuth tokens stolen from the Salesloft Drift integration to pull data out of customers’ Salesforce environments. No password and no MFA prompt were involved; the tokens did all the work.

Resetting the password doesn’t help when the attacker never needed it.

Authenticate and abdicate

This is the core design flaw. Most identity solutions authenticate and abdicate. They do a careful job at the front door with a password, MFA and perhaps a device check, then issue a token and step out of the conversation. From that moment on, each application trusts the token, not the person. (We looked at the architecture side of this in an earlier post, Deciding Is Not Enforcing.)

That creates three problems:

• Trust is checked once and assumed for hours. Anything that changes after login goes unnoticed by the system that granted access: the device gets infected, the session is hijacked, the behavior turns strange.
• The identity provider never sees the traffic. It knows who signed in. It doesn’t know what they reached next, or whether the session is still in the right hands.
• A stronger front door raises the value of the token. The harder the login, the more attackers invest in stealing what the login produces. Strengthening authentication without controlling the session moves the risk downstream instead of removing it.

AI agents turn the gap into a highway

Now add AI agents. Palo Alto Networks’ 2026 Identity Security Landscape report puts the ratio at 109 machine identities for every human identity, with roughly 79 of those being AI agents, and expects agent identities to grow about 85% in the next year. The same report found that nine out of ten organizations suffered a successful identity-related breach in the last 12 months.

Agents run on tokens. An AI assistant connected to your email, CRM and file shares holds OAuth tokens and API keys that give it standing access, often broad, often long-lived and rarely reviewed. There is no MFA prompt for an agent. Every one of those tokens is exactly the kind of credential already being stolen at scale. The Drift breach was a preview. And attackers are using AI too: Microsoft said EvilTokens used AI “at every step of the attack chain,” including a chatbot that combed stolen inboxes for payment approvals and drafted impersonation emails.

Two more factors make it worse:

• Speed. An agent, or an attacker controlling one, can enumerate and extract in minutes what would take a human intruder weeks to find.
• Impersonation. The hardest case isn’t the agent you registered. It’s the one riding inside a user’s session: a browser extension or desktop AI tool acting with that user’s own token. To the identity provider, it is the user. An authenticate-and-abdicate model can’t tell the difference, because it stopped looking after login.

More control points, less control

Most companies answered each new access problem by adding another product: a VPN for remote access, SSO for cloud apps, MFA on top, mobile device management (MDM) for devices, a privileged access tool for administrators, a separate portal for vendors and contractors, and native permissions inside every application.

Each has its own policy engine, its own console, its own logs and its own definition of who is allowed. The administrative workload is real, but it isn’t the biggest cost. The biggest cost is that nobody can answer a simple question with confidence: who can reach what, right now, from where, on which device?

• Policies drift apart. A contractor removed from the VPN may still hold a valid token to a SaaS application.
• Gaps form at the seams. Attackers don’t challenge your strongest control. They look for the application that only one product covers, or none.
• Visibility is split. A token stolen in one system and used in another shows up as two unrelated, normal-looking events in two different consoles.
• Audits become archaeology. Proving who had access at a given moment means stitching together exports from half a dozen tools.

I’ve worked in IT since 1985, and I’ve watched this pattern repeat with every generation of technology: mainframe terminals, client-server, VPNs, SSO, MDM and the cloud. Each new layer solved the problem in front of it and added one more place where access gets decided. Identity security is the latest layer, not the last word.

What actually closes the gap

The answer isn’t to throw out your identity provider. It’s to change where, and how often, the access decision is made.

• One enforcement point for all access. Web, SaaS, remote desktop, SSH, client-server, legacy and OT systems under one policy, one log and one place to revoke.
• Bind more than identity to the session. Device validation, managed-device markers, location and behavior, so a stolen token alone isn’t enough to use the session from somewhere else.
• Decide on every request, not once. Each request is a decision point, not just the login.
• Treat AI agents as their own kind of principal. Identify them, scope what they can reach, and watch for software acting inside a human’s session.

This is the architecture we built Total Access Control (TAC) on at PortSys. TAC sits in front of your applications as a secure reverse proxy, a single gateway every request passes through, so access is evaluated throughout the session rather than only at login. It works with the identity provider you already have; Entra, for example, can remain your identity store while TAC arbitrates access. TAC can bind multiple factors to each session beyond MFA, such as device validation and custom device markers, largely invisible to users. Because it fronts far more than web applications, customers can bring remote desktop, SSH, client-server, legacy and OT access under the same policy and retire overlapping products at their own pace, without a rip-and-replace. We’re extending the same model to AI agents, including detecting agents that operate inside a user’s session.

Three questions worth asking

1. If an attacker stole a valid session token from one of your users today, what would stop them from using it?
2. How many separate places decide who gets access in your environment, and do they agree?
3. Do you know which AI agents hold tokens to your systems, and what they can reach?

If the answers are uncomfortable, identity security alone won’t fix them. Identity tells you who is knocking. Security is deciding, on every request, whether to let them in.

Sources

1. Verizon 2025 Data Breach Investigations Report (credential figures, summarized by Stingrai)
2. SpyCloud, 2026 Identity Exposure Report (Mar 2026)
3. Microsoft Security Blog, code of conduct AiTM campaign (May 2026)
4. Huntress, M365 token spray and replay campaign (Oct 2026)
5. The Hacker News, Microsoft takes down EvilTokens (Sept 2026)
6. Google Threat Intelligence Group, Salesloft Drift data theft
7. Palo Alto Networks, 2026 Identity Security Landscape

Read the list closely and a pattern emerges. Many of these attacks don’t start with an exploit at all. They start when someone presents a valid credential or token, and the system believes them.

The pattern behind the headlines

Consider a few of the incidents the article describes:

• Veradigm. Attackers used a third-party vendor’s credentials to reach patient data, including some Social Security numbers. The company says the impact was limited, but the path in was simple: a trusted identity with a route to sensitive data.
• Murky Panda. According to CrowdStrike, this China-nexus group compromised upstream IT service providers, then moved quietly into those providers’ customers through trusted connections between their Microsoft cloud identity environments.
• Stryker. Attackers reportedly gained access to Microsoft Intune, the cloud service the company used to manage employee laptops and phones, and remotely wiped thousands of employee devices. The disruption reached hospitals, which had to reschedule some surgical procedures.
• Phishing on trusted infrastructure. Phishing kits now run on legitimate developer platforms, and APT29 has sent victims through genuine Microsoft login pages. There is no suspicious domain to catch.

In every case, the attacker didn’t have to break anything. They presented something the environment already trusted, and the environment let them in.

We’ve seen this movie before

I’ve worked in IT since 1985, and this pattern is older than the cloud. Mainframe passwords, VPN credentials, SSO tokens: each generation of access technology made a credential the key, and whoever held the key was trusted. The cloud didn’t create the problem. It multiplied the number of doors that open with a single key, and it made the traffic behind those doors look like normal business.

The lesson hasn’t changed. When one credential is treated as proof of identity, stealing that credential is all an attacker needs.

A credential is evidence, not proof

Total Access Control (TAC) takes a different approach. A username and password, even with MFA, is treated as one piece of evidence, not the whole case. TAC can bind multiple factors of authentication into every session, configured by each customer to fit their environment:

• Credentials and MFA
• Device validation, confirming the session comes from a known, approved device
• Registry entries and secret files that exist only on legitimate endpoints
• Other unique, customer-defined markers

Bound together, these factors change the math for an attacker. Credentials harvested in a breach, phished from a user or bought from an initial access broker don’t create an immediate opening. Without the validated device and the markers that live on it, the login doesn’t complete.

Just as important, most of these factors work behind the scenes. Users don’t see extra prompts or juggle more codes. Security goes up without adding friction or feeding the MFA fatigue that attackers exploit.

Where the access decision is made matters

Strong authentication only protects what sits behind it, so architecture matters as much as features.

Organizations get the most protection when TAC is the front door. In that model, every session passes through TAC first, and TAC evaluates all of the configured factors before the user reaches any application or cloud service. If TAC protects only some applications, sessions that go directly to other services never pass through those checks.

An example of this is Microsoft 365, the cloud service many organizations use for email, documents and collaboration. Users typically sign in to Microsoft 365 directly, with their usernames and passwords verified by Microsoft Entra ID, Microsoft’s cloud identity service. With TAC as the front door, that sign-in is redirected from Microsoft to TAC. TAC sees the session first and checks the device, its markers and every other configured factor before the user ever reaches Microsoft 365. User accounts can stay in Entra ID; TAC simply decides who gets through.

Some organizations instead let users sign in to Microsoft 365 directly and use TAC to protect specific applications. Those applications are still protected, but Microsoft 365 sessions don’t pass through TAC’s checks. If credential theft and token abuse are on your risk list, and after this article they should be, it’s worth reviewing where your access decisions are actually made.

There’s a second benefit. Applications behind TAC aren’t exposed to the internet. The article describes attackers spinning up thousands of short-lived cloud functions to scan networks from high-reputation IP addresses that firewalls can’t block. Blocklists don’t matter when there’s nothing exposed to find.

What this does and doesn’t solve

Not every technique in the article is an access problem. Malware that hides its command channel in Google Sheets or AI APIs, data exfiltration through Slack or Discord, and attacks on cloud metadata services and snapshots call for endpoint, egress and cloud posture controls. And if an attacker is already running on a legitimate user’s device, device-based factors are present by definition. Defense in depth still applies.

But a large share of these attacks begin with an identity the environment trusts too easily. That part is solvable, and it’s where attackers get the most leverage for the least effort.

Questions to ask about your environment

• If a vendor’s credentials leaked today, what else would an attacker need to get in?
• Which applications can be reached with a username, password and MFA alone?
• Where is the access decision made: before users reach your applications and cloud services, or after?
• Do your additional authentication factors add security without adding friction for users?

If those answers aren’t comfortable, let’s talk. PortSys has been helping organizations control access since 2008, and we’re happy to walk through how TAC would fit your architecture.

Source

• John Leyden, “14 ways attackers abuse cloud services to hack your enterprise,” CSO Online, October 21, 2026

Since then the industry has caught up, and a category of products has formed to solve it. That is progress, and the argument we made stands.

This post is about the half of the problem those products do not reach.

Because almost everything being built to govern agents rests on the same assumption.

That the agent tells you what it is.

What is being built

The emerging approach is an identity approach, and on its own terms it is sensible. Agents get registered. They are issued their own credentials rather than borrowing a person’s. They attest to what they are. Their permissions are scoped to a defined task, and their activity is attributed to them rather than disappearing into a human’s audit trail.

If you are deploying agents deliberately — procured, catalogued, wired into systems on purpose — all of that is worth doing, and organizations that skip it will regret it. That is the case we made last October and we would make it again.

But every one of those controls begins at the same place: something arrives, declares itself, and is evaluated on the strength of that declaration.

Two cases the declaration does not cover

The agent operating inside a human’s session

A person authenticates. Correct credentials, compliant device, a session opened for entirely legitimate reasons. Something then acts through that session on their behalf — a browser extension, an assistant with access to the desktop, a tool the user connected to their own account last month because it saved them an hour a week.

At the front door there is nothing to see. The authentication was valid, because it was the human’s. No new principal appeared. No registry was consulted, because nothing asked to be registered.

This is not a hypothetical failure mode. It is the ordinary way agents are reaching enterprise systems today, in most organizations, without anybody having decided that it should be so.

The thing that will not be declaring anything

The second case is simpler. An attacker’s tooling has no interest in attestation. Neither does a script somebody wired up on a Friday, or malware behaving the way malware now behaves.

A governance model built on cooperative declaration governs the cooperative. That is worth saying plainly, because it is easy to buy a registry and believe the problem has been addressed.

Why this cannot be closed at the front door

If the only point at which a system observes access is the moment of authentication, then an agent operating inside an authenticated session is not a gap in the policy. It is invisible to the mechanism entirely.

There is nothing anomalous to detect. The credentials were right. The device was compliant. The decision was correct. Everything the system was designed to examine looked exactly as it should.

An architecture that is not in the path of the session cannot inspect what happens inside it — not because of a missing feature, but because that traffic never passes through it. This is the same structural limit that decides which applications a platform can front, arriving in a different form.

Identification still matters — but only from inside the session

None of this argues that identifying agents is unimportant. It matters a great deal, and the case that matters most is precisely the one a registry cannot help with: determining whether a session that authenticated as a person is actually being driven by one.

That determination is possible. But it cannot be made at the point of authentication, because at that point there is nothing to observe. It can only be made from inside the session, by watching what the session does — the pace and regularity of requests, the pattern of what is reached and in what order, behavior no person sitting at a keyboard would produce.

Which brings the argument back to position. If you authenticate and then abdicate, you have no way to identify malicious behavior during a session. You have a verdict on who knocked, and nothing whatsoever on what came through the door.

Being in the path is not only what lets you contain an agent you failed to identify. It is what gives you the chance to identify it in the first place.

A different question

And identification will sometimes fail regardless. So the second question, asked alongside the first rather than instead of it: what can any session reach if you do not spot what is driving it?

That reframing changes what a control has to accomplish. Identification is a race — new agent types, new tooling, new ways of blending into legitimate activity, and a detection model that must stay current with all of it. Containment is not a race. It does not depend on recognizing the thing at all.

What containment looks like in practice

Total Access Control publishes the resource, not the network.

A session is granted access to specific applications. It does not receive a route onto a network from which other things are reachable, because there is no route to receive. Everything the session does passes through the enforcement point, and the enforcement point is still there for the duration.

So if something is operating inside that session — an agent the user connected, an agent nobody knows about, or something considerably worse — it is confined to what the session was granted. Not because it was identified. Because there is nowhere else to go.

The blast radius stops being “whatever is reachable from the network” and becomes “the resources this session was granted”. For an undetected agent, that difference is the entire outcome.

What is actually being argued

Registering agents, issuing them their own credentials and attributing their activity are all good practice. We said so a year ago and nothing since has changed our view. An organization deploying agents deliberately should do all three.

The argument is about what you depend on, and where the work happens. A model that only works when the agent cooperates has a defined failure mode, and that failure mode is the adversarial case — the one that matters most. Observation from inside the session is what narrows it. Containment is what holds when it fails anyway.

Neither is available to something that stepped out of the path.

The question worth asking

Not: can we tell which agents are operating in our environment?

But: if one is operating that we cannot see, what can it reach — and how would we know what it reached?

If the answer to the first half is “whatever the user could reach from the network”, then the agent question is not really an agent question. It is the same architecture question, arriving with a new name.

You bought a modern access platform. It was deployed. It works. People are pleased with it.

And the VPN is still running.

What it is still there for

Ask which applications still require it and a list appears. It is never a long list, and it is never written down anywhere in full.

Thick clients. Something that expects a Kerberos ticket. An OT segment where the device initiates the session. A system a vendor supports on the condition that nothing about it changes. Possibly an acquisition that was never properly integrated and now never will be.

That list is the hard half of your estate. The new platform covered what it could cover, which was the applications that were easiest to cover — and that was a reasonable place to start, because it delivered value quickly and demonstrated the model worked.

Nobody did anything wrong. But the project that was supposed to retire the VPN did not retire the VPN.

So you added. You did not replace.

This is the point at which it stops being a procurement footnote and becomes an architecture problem.

You now run two access paths in parallel where you meant to run one. That is another internet-facing doorway on top of whatever was already exposed — another management plane, another set of credentials, another vulnerability stream, another thing to patch when an advisory lands on a Friday afternoon.

And it is worth being honest about the count. It is rarely two. Alongside the VPN and the new platform there are usually applications published directly to the internet, a remote-access route somebody set up for a supplier, an administrative interface that was only ever meant to be temporary. Every one of them is a doorway that has to be defended.

Both serve the same estate. Neither covers all of it.

The attack surface did not shrink. It grew — as the direct result of a project justified in part on shrinking it.

The business case nobody restated

Somewhere there is a paper that made the case for the new platform, and somewhere in that paper is an assumption that the VPN would be retired. License savings, perhaps. Reduced operational burden. One fewer thing exposed.

Nobody went back and revised it once the assumption turned out to be false.

That is not dishonesty. Nobody ever goes back. Projects are judged on whether they delivered what they said, and this one did — it just also left something behind that the case had assumed would go away.

The consequence is that the cost of the hard half has never actually been counted. It sits in the estate as a running expense and a standing exposure that no business case has ever had to justify.

And now the VPN is neglected as well as exposed

This is the part that should be uncomfortable.

Once a system is designated legacy and scheduled for removal, it stops attracting investment. The version upgrade is deferred — why upgrade something being retired next year. Access reviews slip, because the population using it is small and shrinking. Dormant accounts linger. The firmware is a version behind, then two. The engineer who understood it best moved to the team running the new platform.

Meanwhile it remains an internet-facing route onto your network.

A deprioritized front door is more dangerous than a maintained one. So the position is not simply that you failed to remove the VPN. It is that the VPN you still have is less well looked after than the VPN you had before the project started.

Why it is still there is the actual problem

The VPN persists for one reason: nothing available could front the awkward applications, so the old path had to stay for them.

That reason does not change by buying another platform with the same boundary. A second modern product, brokering access from outside your directory in the same way, produces the same outcome — another layer, another front door, and the same list left over at the end.

The list is the problem. Everything else is a symptom of the list.

What actually removes it

An enforcement point that can front the hard half.

Total Access Control terminates the session in front of the application, inside your environment — and it does that for the whole estate, not for a category of it. The SaaS and cloud applications your current platform already handles well, the internal web applications, and the ones that would not move.

Because it is inline — in the path of the transaction rather than alongside it, and operating within your identity environment rather than brokering from outside it — it can present the identity an application actually expects: a Kerberos ticket, an injected header, a session into an OT segment where the device initiates the connection. The awkward applications stop being awkward, because the thing in front of them speaks their language.

Where it runs is a separate question and a free one. Datacentre, private cloud, public cloud — that is a deployment decision to suit the estate. What matters architecturally is that it sits in the line between the user and the resource, for the whole session, rather than issuing a decision at the front door and stepping aside.

That distinction is the point. Something that fronted only the difficult applications would leave you with two platforms instead of one — which is the position you are already in, with better branding.

It goes in beside the VPN, not instead of it. One population moves — usually third parties or remote administrators, the group with the most risk and the least tolerance for a laptop rollout. Both paths run side by side. The next group moves once the first has become boring.

The VPN shrinks until it has nothing left to serve. At that point removing it is an administrative task rather than a project, which is the only way these things ever actually get removed.

Some estates keep one for a single purpose indefinitely, and that is a perfectly good outcome — provided it is a decision someone made rather than a residue nobody got around to clearing.

And the next one is already being sold to you

AI agents are arriving in production estates now. They act on behalf of people, they hold credentials, and they make requests against the same applications your staff use. A category of products is forming to govern them.

When one is put in front of you, the questions worth asking are the ones nobody asked about the platform that was supposed to reduce the number of doorways and instead added one:

• Does this make my life easier, or does it add another console to watch?
• Does it give me more control over access, or does it move some of that control somewhere else?
• Will people and agents be governed in one place, or in two?
• When this is deployed, what is left over — and who owns it?

None of those questions are about AI. They are the questions that should have been asked about the last platform, and the one before that.

The pattern is not the VPN. It is the assumption that covering part of the estate counts as progress.

So: why do you still have a VPN?

If the answer is a list of applications, that list is your architecture problem.

It is the thing to solve — not the VPN, and not with another platform that cannot reach the things keeping the VPN alive.

How many separate products currently have a say in whether a given person can reach a given application?

Firewall rules. A VPN. Perhaps an application gateway, perhaps a web gateway. Things published directly to the internet because at the time that was the pragmatic answer. SSO. MFA. MDM. Conditional access policies. And now, most likely, a cloud-delivered access platform bought in the last three years.

Most people get to seven or eight and become unsure whether they have missed one. That uncertainty is the finding. If the number cannot be stated confidently, nobody in the organization can answer the question those products exist to answer.

I wrote this in 2019

In March 2019 I published a post here called “The Madness of IT Security Sprawl”. I have just reread it, and the uncomfortable thing is not that parts of it are dated. It is that none of it is.

Here is what I wrote then:

“The reality is that the more security products you have, the more fronts you must defend. That complexity is magnified with every additional security product you throw at this tidal wave of attacks.”

And this, which I would now revise in only one respect:

“There is no truth to the commonly held belief that the more solutions deployed, the harder it is for an attack to be successful. That approach has been tried for the past three or four decades, and it still doesn’t work.”

The revision is the number. In 2019 it was three or four decades. It is now four or five.

The list, then and now

The 2019 post named what organizations were running. I listed: two-factor authentication, single sign-on, administrator access, partner access, customer access, file access, VPN, mobile device management, cloud access, RDP.

Read that list again and notice what is not on it.

No cloud-delivered access platform. No SASE. No agent governance of any kind. Those are the things that have been added since — and not one of the ten items on the original list has gone away in the meantime.

That is the whole argument in two lists. Seven and a half years, several new categories, nothing retired.

What I got right, and what I would say differently

The 2019 post said: consolidate your security. I still believe that, but the word has since been taken.

Every large vendor now sells consolidation. Platform, single pane, unified policy — the language is universal, and much of it is sincere. So “consolidate” is no longer a differentiating claim, and repeating it in 2026 would be joining a chorus rather than making a point.

What the chorus does not do is consolidate all of it. A platform consolidates the applications it can reach — and for most of them, that means the modern ones. The thick clients, the systems expecting a Kerberos ticket, the OT segments, the legacy applications behind an injected header stay outside, on whatever was there before.

Partial consolidation is not consolidation. It is a smaller number of larger pieces, which is an improvement in operations and no improvement at all in architecture. The platform becomes one more item on the list rather than a replacement for it.

That is the sharper version of the 2019 argument, and it took the intervening years to see it clearly.

It used to be one place

I have worked in IT since 1985. When I started, access control was centralized — not as a philosophy, but as a consequence. There was one system. A terminal, a mainframe, and one place that decided who could reach what.

Nobody called that an architecture. But it had a property worth naming: there was exactly one place where the question was answered, and therefore exactly one place to look when you needed to know the answer.

Everything since has been the story of losing that property, one reasonable decision at a time.

Forty years of partial fixes

Client-server distributed the decision across machines nobody controlled centrally. Connecting to the internet brought the firewall, to decide what could come in at all. Remote working brought the VPN — a second front door, with its own rules and its own administrators.

The VPN granted more than it should, so application gateways and web gateways arrived to constrain what happened after it. There were now too many places to authenticate, so SSO. Passwords stopped being sufficient, so MFA. The device stopped being ours, so MDM. The application stopped being ours, so cloud access brokers.

And when all of that still could not answer the question, the industry produced a new category to answer it properly.

Every one of those solved a real problem. Every one was, at the time, the right purchase. And every one answered part of the same question in a new place.

The seams grow faster than the products

This is why the estate feels harder to reason about every year even though each individual purchase was sound.

Three systems have three boundaries between them. Eight systems have twenty-eight. Each boundary is a place where two policy models meet and can diverge — and no boundary belongs to anybody. The team running each system owns the system. Nobody owns the space between them.

Policy divergence at those boundaries is not a failure of diligence. It is the arithmetic.

And nothing is ever actually removed

Products get replaced, in the sense that a newer one is bought. But the newer one covers a subset, so the incumbent survives for the remainder.

Look at what is still running in your estate right now. Firewall rules written by an engineer who left in 2017. An MDM deployment for a device population that has shrunk to forty handsets. A gateway kept alive for one application. A VPN that was supposed to be retired eighteen months ago.

None of it is anyone’s fault. Each was superseded rather than removed, because removing it entirely would have meant solving the awkward remainder — and the awkward remainder is always the expensive part.

The current generation is doing it again

Cloud-delivered access platforms cover what they can reach and leave the rest. The applications that could not move stay on the old path, and the old path stays with them.

That is not a criticism of a category. It is the same pattern, in the current decade, for the same structural reason. I have written separately about what it looks like from the inside — the question of why, after buying a modern access platform, you still have a VPN.

Why I think this is the breach story

I would argue — and it is an argument, not a citation — that this is the main reason breaches keep happening to organizations that are spending seriously on security.

Not because they underspend. Spending has risen steadily for two decades. Because the answer to “who can reach what” is distributed across a dozen systems that cannot see each other, and an intruder does not need to defeat that architecture. They need one seam between two parts of it.

Nobody is defending the seams, because the seams are not on anyone’s list.

The next one is already here

AI agents are being deployed into production estates now. They act on behalf of people. They hold credentials. They make requests at machine speed, against the same applications your staff use.

And a category of products is forming to secure them.

So here is the question worth asking before buying one: will governing what an AI agent can reach be a separate system from governing what a person can reach?

If the answer is yes, then to borrow my own words from 2019: that is one more front to defend. Humans decided in one place, agents in another, and a fresh seam between two populations that will increasingly do the same work against the same systems.

In five years someone will write a post about the AI access product nobody could remove, because it covered part of the estate and something had to stay behind for the rest.

The pattern never announces itself as a pattern. It arrives as a reasonable purchase, with a good demo, solving a real problem.

An AI agent is a principal making a request. If the place where access is decided already evaluates who is asking, in what context, against what policy, for every request — then an agent is another kind of requester, not another product category.

This is not nostalgia

The mainframe was not better. I am not proposing a return to 1985, and anyone who lived through it would not want one.

The point is narrower than that. One property of that era was worth keeping — that a single place decided who could reach what — and it was lost as a side effect of forty years of necessary changes, rather than because anyone decided it should be.

What has changed is that keeping it is now possible again. A single enforcement point can sit in front of the whole estate — and the word that matters there is whole.

The SaaS applications and cloud workloads a modern platform already handles well. The internal web applications. The thick clients. RDP and SSH sessions. OT environments. The legacy systems expecting a Kerberos ticket or an injected header. And the agents now arriving alongside the people.

That distinction is worth being precise about, because a product that covered only the difficult half would be another partial answer — one more item on the list, and exactly the thing this post argues against. The claim is not that we specialize in what others cannot reach. It is that one place decides, for everything.

Not as a migration. One population at a time, beside whatever is already there, until each old path has nothing left to serve.

Count them again in two years

That number should be going down.

For most organizations it has only ever gone up — and the next increment is already on the roadmap, wearing the word “AI”.

It does not have to. Stop the madness.

After the product has decided someone may connect — where is it?

Two architectures

In the first, the product evaluates the request at connection time. Identity is checked, policy is applied, a decision is reached, and a path is established between the user and the resource. The product then steps out of the way. Traffic flows.

In the second, the product terminates the session. It is one of the two parties in the connection — the user connects to it, and it connects to the resource. It remains in that position for the life of the session.

That is the difference between a broker and a reverse proxy. Both are real designs with real deployments behind them, and the distinction is not about which vendor is more capable.

But the consequences diverge more than the diagrams suggest.

What happens at the moment of connection

A product that brokers access from outside your identity environment can establish a path to almost anything. Most handle RDP and SSH perfectly well — carrying a protocol is not the hard part, and any claim to the contrary is wrong.

The hard part is what the application expects to receive when the user arrives.

An application that authenticates users itself — a modern web application speaking SAML or OIDC — needs nothing more than to be reachable. For that, brokering is entirely sufficient.

An application that expects its environment to have already established who the user is needs something else. It wants a Kerberos ticket obtained for that user, for that service. Or a header set by a component it trusts, positioned where it expects that component to be. Something has to produce that, and producing it requires being a participant in the transaction rather than an observer of its beginning.

This is why the awkward applications are awkward. Not the protocol. The identity.

What happens during the next four hours

The second divergence is larger and gets discussed less.

A product that stepped aside made one decision, at one moment, based on the state of things at that moment. Everything after that is outside its view. It can decline the next connection. It can do nothing about this one.

That matters in three distinct ways, and only the first is usually discussed.

The device stops being what it was

Posture at connection is not posture an hour later. The endpoint agent is stopped. A drive is attached. Something is installed. The machine that satisfied policy at 09:00 would fail it at 11:20, and nothing is asking.

The session reaches for things it was never granted

This one is larger. A decision at the front door authorizes access to something. It cannot verify that the session is subsequently used only for that.

If what is inside the session begins reaching for resources that were never part of the request — scanning, enumerating, following a path sideways — an architecture still in the line sees those attempts, because they have to pass through it. An architecture that stepped aside sees nothing, because that traffic never comes near it.

This is the difference between authorizing access and controlling it.

The attack begins after the connection

The most consequential case, and the hardest for a front-door model to address at all.

The credentials were valid. The device was compliant. The decision was correct. And then the session becomes the delivery vehicle for something that starts afterwards — a compromised endpoint, a stolen token replayed from elsewhere, a process acting through a session a human legitimately opened.

Every check happened before the thing that matters began.

In all three cases the original decision was right. That is what makes this a hard problem rather than a careless one: nothing was wrong at the moment of the decision, and nothing after that moment was examined.

Authentication is a moment. Access is a duration. Most access products are excellent at the moment.

And what ends up in the log

A third consequence, and the one that surfaces during audits.

If the enforcement point is only present at the start, its records describe admissions: who authenticated, when, from where, and whether the request was granted. That is an authentication log wearing an access log’s name.

Something in the path for the whole session can record what was actually reached. Those are different questions, and only one of them is the question an auditor asks.

Inline is a position, not a place

One clarification, because the language invites a misreading.

Being inline is about where a product sits in the transaction, not where it sits geographically. A reverse proxy can run in a datacentre, a private cloud or a public cloud. That is a deployment decision, driven by where the applications are and how the organization prefers to operate.

What matters architecturally is that it is in the line between the user and the resource, and that it operates within the identity environment of what it protects rather than brokering from outside it. Both of those are true wherever it happens to run.

“Cloud-delivered” and “brokered from outside” are frequently the same thing in practice, but they are not the same claim, and it is worth keeping them apart when comparing products.

Why this decides which half of your estate you can cover

These two consequences are not independent of the coverage question. They are the reason for it.

The applications that resist migration to a modern platform are the ones that expect identity presented in a particular form. That is the connection-time consequence. And they are frequently the applications where a point-in-time decision is least adequate — administrative access, industrial systems, anything where a session running for hours does more than read a page.

So a product that is not in the path is not merely less thorough. It is structurally unable to reach part of the estate, and the part it cannot reach is disproportionately the part that matters.

The question to ask any vendor

Not “do you support RDP”. Everyone supports RDP.

Ask instead: two hours into a session your product authorized, where is your product? If the device has stopped being compliant, what happens? And if something inside that session starts reaching for resources it was never granted, which component sees the attempt?

Ask us the same question. The answer should be specific, and if a product cannot do something, that is far better learned in a conversation than in a pilot.

That order is a decision. It was made a long time ago, by people solving a different problem, and almost nobody has revisited it since. But it is still being paid for — and the license is the smallest number in the story.

What the order costs

Consider what exists in a typical estate purely to constrain something that has already been granted.

Segmentation, to limit where a connected session can go. Micro-segmentation, because segmentation turned out to be too coarse. Network access control, to decide what is allowed to connect in the first place. Monitoring, to record where sessions went. Detection, to notice the ones that went somewhere they should not have. Lateral movement detection, which is a product category that exists because lateral movement is possible.

Every one of those is a sensible purchase in isolation. Each was bought by a competent person for a good reason. Together they represent a substantial share of a security budget, they each carry a console, a license and an owner, and they are all downstream of the same architectural choice: access is granted at the network level first, and constrained afterwards.

None of them are wrong. They are compensating controls, and what they are compensating for is the order.

So when the VPN comes up for renewal and the number looks reasonable, that number is not the cost of the VPN. It is the entry fee.

Why it never gets cheaper

The pattern is worth noticing, because it is the reason this line item grows every year and never shrinks.

Each layer is purchased to address the coarseness of the layer beneath it. Segmentation was too broad, so micro-segmentation. Rules became unmanageable, so a policy engine to manage the rules. Alerts outpaced the team, so a platform to triage the alerts. At no point is anything removed, because the thing beneath is still load-bearing.

This is the same accumulation described in “Stop the madness” — additions layered on additions — arriving here as a budget rather than as an attack surface. It is not a spending problem. The spending is the symptom.

Reverse the order

If a session reaches one application and no route onto the network exists, there is nothing to segment and nowhere to move sideways.

That is not a claim that detection and monitoring become unnecessary — you still want to know what happened, and no serious estate runs without them. It is a claim about how much work they are being asked to do. A control that constrains movement is doing very different work in an estate where movement was never possible in the first place.

The question this puts to any access product is a simple one: after it has decided, what does the session actually hold? A credential for one application, or a position on a network with an access control list drawn around it?

Where this is sharpest

Industrial and critical infrastructure environments, which is part of why they keep appearing in breach reporting.

Access into a plant network is frequently a VPN and a shared credential, with segmentation as the only thing standing between a contractor’s laptop and a controller. The access control was never designed. It was inherited — from a period when the plant network was not reachable from anywhere that mattered, and the assumption survived the thing that made it true.

The shape is identical in an office estate. It is simply less consequential when it fails.

And it has to be the whole estate

One caution, because this is where the argument is usually half-implemented.

Reversing the order for the applications that were easy to move, while the difficult ones stay behind a network-level path, does not reverse anything. It produces two orders running in parallel — per-application access for one group of systems, grant-then-filter for the rest — and the compensating control stack stays exactly where it was, because it is still holding up the half that did not move.

The saving is not in changing the order for some things. It is in not needing the compensating layer at all, and that only happens when there is nothing left underneath it. Which means the enforcement point has to be able to front the cloud and SaaS applications the organization has already modernized, the internal web applications, and the awkward ones that resisted every previous attempt — from one place.

The objection, which is correct

The VPN works. Everyone depends on it. Replacing it touches the whole organization at once, and the project would be judged on the week it went wrong rather than the two years it went right.

All of that is true, and it is why an architecture that everyone involved agrees is wrong outlives the people who inherited it. It is also why the sensible move is not a replacement. Total Access Control goes in alongside what is there and takes one population at a time — the mechanics of that are in “Why do you still have a VPN?”, and the point here is only that the order can be changed incrementally. It does not require a cutover date.

The order decides the blast radius — including for things you cannot see

There is a reason to settle this before the next wave of products arrives rather than after.

AI agents increasingly act inside sessions that a person opened legitimately. Whether any given one is identified, registered and well behaved is a separate question, and a real one. But what it can reach if it is not identified is decided entirely by the order.

On a grant-then-filter path, an agent operating inside an authenticated session inherits the network that session was placed on, and the compensating controls are the only thing standing in the way — the same controls that were already struggling with human sessions. On a per-application path, it inherits the application. Nothing about the agent changed. The ceiling did.

Products being built to govern agents will address identification. Very few of them will change what a session holds, and that is the half that determines the damage.

The question this raises

If someone had valid credentials for your VPN this afternoon, how far would they get before anything stopped them?

If the honest answer is “further than I would like, but segmentation would probably contain it”, that is the compensating control doing the work the architecture should be doing — and you are paying for both.

That single fact removes every control the rest of your estate depends on, and the usual answers are all attempts to get it back. Ship them a laptop, and you have spent procurement, imaging, shipping and recovery on one application — and the device is out of your sight for six weeks. Make them install an agent, and their IT may refuse, their security policy may prohibit it, and a supplier with leverage will simply decline. Give them a VPN account, and you have placed an unmanaged machine on your network with an access control list as the only thing deciding where it can go.

And when all three are slow enough or contentious enough, the fourth answer happens instead: an account gets shared, a screen-share becomes the access method, or the data is extracted and emailed and now sits on that machine permanently with nothing attached to it at all. That one never appears in an access review, because from the system’s point of view no access was granted.

The part that cannot be fixed

Underneath all four is the same condition, and it is worth stating plainly because it does not go away.

You cannot see what is on that device. Not the browser extensions, not the assistant with access to their desktop, not the tools they connected to their own accounts last month, not whatever arrived with them. You cannot inventory it, you cannot mandate what may be installed, and anything the machine reports about itself is a claim from a system you do not control.

This is a permanent condition, not a gap waiting for a product. Every approach that depends on knowing what is running on the endpoint — including the emerging model for governing AI agents, which asks agents to register and declare themselves — is defeated here by definition. No registry you deploy covers a contractor’s laptop.

So change the question

The question is not how to make an untrusted device trustworthy. You cannot, and the effort spent trying is the reason third-party access takes six weeks to arrange.

The question is how much it matters that it is untrusted — and that is entirely within your control, because it is decided by what the session is allowed to be, not by what the device is.

There are four ways to reduce it. They apply in order, and they compound.

First and second: validate, then bound

We have covered these two before, so briefly.

The session is established against the enforcement point, where identity, authentication strength, context and whatever device signals are genuinely available are evaluated — at the point of access, per request, rather than on an endpoint you cannot instrument. Then the session is given the resource rather than the network: it reaches the one application it was granted and receives no route onto anything else, because there is no route to receive.

The consequence is the one we described when we wrote about contractor and third-party access last February. Whatever is riding along inside that session — an assistant the contractor connected, malware they do not know about, an agent that never declared itself — is confined to exactly what the contractor was granted. Not because it was detected. Because there is nowhere else to go.

One caveat worth stating plainly, because it is the claim a technical reader will test: the device signals available from an unmanaged machine are not the signal set a managed endpoint produces, and any vendor telling you otherwise is selling you something. The comparison that matters is not with a corporate laptop. It is with the VPN account that was the realistic alternative, which asked nothing at all.

Third: move the critical path off the device entirely

For the access where bounding the radius is not enough, there is a further step, and it is the one that changes the risk rather than limiting it.

The application is published so that it executes in a controlled environment you do own — delivered to the contractor as a remote session rather than run on their machine. They interact with it. The application, its data and its credentials never land on the endpoint. What they are holding is a window.

This is the answer for the access that would otherwise be refused outright: an administrative tool, a system holding regulated data, the thing a supplier needs that nobody is comfortable exposing. And critically, it is applied after the session has been identified and validated against policy, not instead of it. Isolation is where a validated session is placed. It is not a way of skipping the validation.

Fourth: set the terms of the session yourself

Which raises the question a security reviewer asks immediately, and it is the right question. A remote session that permits clipboard, drive mapping and printing has moved the application off the device and handed the data straight back.

So those are not defaults to be inherited. They are parameters, and Total Access Control carries them into the session it publishes — what may be copied, what may be printed, whether local drives are mapped, what the window is permitted to do at all. The terms of the remote session are set by your policy rather than by whatever the endpoint or the protocol would allow if nobody specified.

And the same applies to getting data out through the ordinary path. File download can be filtered on authentication strength, device posture and context — so the capability is not a property of the application, it is a property of this session, opened by this person, from this device, in these circumstances.

That conditionality is what makes the whole thing workable commercially, because it means you rarely have to answer no.

The supplier who will not install an agent is not refused. They are given a session with no clipboard, no drive mapping, no printing and no download, into an application running somewhere you control. The same person, later, from a managed device with stronger authentication, gets a session with more in it. Nobody negotiated. Nobody made an exception. The policy simply produced a different session, and both are recorded the same way.

That is the graduated response. Ordinary access gets a bounded session. Sensitive access gets an isolated one. Risky context gets an isolated one with the exits closed. Every one of them is a policy decision on the same platform, made per user, per application, per context — rather than a separate product bought for each tier of risk.

And all of it stays in one place

None of the above is a separate product, and that is the part that matters more than any individual control.

Solving third-party access by buying a dedicated third-party access product solves third-party access and leaves the estate worse — another console, another policy model, another set of logs that has to be correlated with the others during an audit. That is exactly the pattern that produced the sprawl in the first place.

The same enforcement point that handles the contractor handles employees, remote administrators, an OT segment, the cloud and SaaS applications already running well, and the internal applications nobody could move. One policy model. One set of logs recording what was actually reached, by whom, on what. One place to answer an auditor, and one place to change your mind when the contract ends.

Third-party access is simply the case where the argument is easiest to see, because it is the case where you can watch every assumption fail at once.

Where to start

Take the third-party access path you would least like to explain to an auditor, and ask two questions about it.

What does this grant beyond the one application it exists for — and if that machine is already compromised, what have we actually lost?

It is not an unreasonable request. It is close to the most ordinary request in security operations, it comes up in audits, investigations and offboarding reviews, and most organizations can eventually answer it. The word doing the work in that sentence is “eventually”.

What comes back first

The first answer is a list of authentication events. This person connected at these times, from these addresses, with these methods, and the connection was permitted.

That is a real record and it is genuinely useful. It also does not answer the question that was asked. The question was what they reached; the answer describes that they were admitted.

The distinction is easy to lose because the system producing those records is usually called an access log. It is an admissions log. Everything it knows, it learned at the door.

Why the record stops at the door

This is not a logging deficiency, and it will not be fixed by increasing the log level.

If a product evaluates a request at connection time, establishes a path, and then steps out of the way, its records can only describe what it observed — and what it observed was the connection. The traffic that followed did not pass through it. There is nothing for it to withhold.

A component that remains in the path for the duration of the session is in a different position. Every request traverses it, so its record can describe resources rather than admissions.

Same question, two architectures, two different kinds of answer — and the difference is decided long before anybody configures logging.

So the answer gets assembled

Because the primary record is incomplete, the real answer is built from fragments. Everybody who has done this recognizes the shape of it.

Connection records from the remote access platform, to establish when the person was on. Application logs from each system they might have used, in whatever format each one produces. Directory group membership, to determine what they could have reached — though membership today is not membership in April. Jump server records, if there is a jump server. Possibly a ticketing system, to establish what they were supposed to be doing.

Then somebody correlates it. Timestamps in different zones, identifiers that differ between systems, a person whose account name changed when they moved teams.

It is skilled work, it takes days, and it is done under time pressure by people who had other commitments that week. The output is a narrative rather than a record — and a narrative assembled by inference is a weaker thing to hand an auditor than a record that was simply kept.

The gaps are structural

The harder problem is what correlation cannot recover.

If a session reached a system that produces no useful application logging — and the applications that resisted modernization are disproportionately in that group — then nothing anywhere recorded it. The remote access platform saw a connection. The application recorded nothing worth having. The access happened and left no trace.

The honest answer to “did they reach this system?” is then “we cannot tell”, which nobody wants to write down and almost nobody does. What gets written instead is what the evidence supports, with the systems that produce no evidence quietly absent from the report.

This is the part worth sitting with. The absence is invisible. A report assembled from the systems that keep records looks complete, because the systems that keep no records contribute nothing to it — including no indication that they are missing.

The three questions, and which ones you can answer

Audit requests reduce to three, and they have different evidentiary requirements.

Who had access to this system? Answerable from entitlements rather than logs, provided entitlements are reviewed and the review is evidenced. Most organizations manage this one.

Who used it, and when? Requires records tied to the resource rather than to the connection. This is where the assembly work starts.

What did they do while they were there? Belongs to the application, if it keeps such records and if they can be correlated to the person rather than to a service account.

An admissions log answers the first and gestures at the second. The gap between what the second question needs and what the connection record provides is the whole of the correlation exercise.

What a record kept at the right place looks like

If the enforcement point is in the path of every request, the request and the resource are in the same record, because it saw both.

That is the entire difference. Not a superior logging implementation — a position from which the useful facts are observable in the first place. Total Access Control terminates the session in front of the resource, so what it records is per-resource rather than per-connection, for every application it fronts.

The practical effect is that the quarter-of-a-contractor question becomes a query rather than a project. Which matters less for the audit than for everything else: the same record is what an investigation needs at two in the morning, and it is what a manager needs when somebody asks whether a leaver still had access to the thing they should not have.

A test worth running before someone asks

Pick a person and a quarter. Ask for everything they accessed, across every system, and note how long it takes and how many sources it draws on.

Then ask the harder half: which systems could they have reached that would not appear in that answer at all?

The first number tells you what an audit will cost. The second tells you what it will miss.

This one is about something more mundane and, in practice, more expensive. Almost nobody has written down which of their applications are on the wrong side of it.

Everyone knows. Nobody owns the set.

Ask any individual engineer about any individual application and you will get a precise answer. The knowledge exists. What does not exist is the set.

The reason is structural rather than careless. Each of these applications became an exception inside a different project — a migration, a platform rollout, an acquisition integration, a compliance remediation. Each exception was documented where that project documented things, approved by whoever was accountable at the time, and given a review date. Then the project closed. The people moved. The documents went wherever closed project documents go.

The exceptions persisted. The record of them dispersed. And because no single program ever owned the whole set, no single program was ever asked to produce it.

What it costs to not have the list

Three consequences, and the third is the one that keeps the situation stable for years.

You cannot scope an evaluation

Every access product will tell you it supports RDP and SSH, and most of them genuinely do. The discriminating question is not about protocols — it is whether a product can front the specific applications you have. Without the list you cannot ask that question, so you evaluate on features instead, and discover the gap during a pilot.

You cannot describe the risk

“Some older applications are still on the VPN” is not a statement anyone can act on. A page naming eleven systems, four of which hold regulated data and two of which are reachable by third parties, is a different kind of document entirely — and it is the same information, just assembled.

You cannot cost it, so it never competes

This is the important one.

Budget goes to problems with numbers attached. A problem that exists as scattered exceptions in closed project documentation has no number, cannot be put on a slide, and therefore never appears on the list of things being funded this year.

So it remains a running expense and a standing exposure that no business case has ever had to justify — not because anyone decided it was acceptable, but because nobody has ever been in a position to ask for the money. The cost is real and it is being paid. It is simply being paid invisibly, which is the only condition under which a cost survives indefinitely.

Write the list

One page. For each application that did not move, four columns:

• What it expects at the point of authentication — a Kerberos ticket, a header set by a trusted component, a local account, nothing at all.
• Who needs to reach it, and from where. Staff, administrators, third parties, equipment.
• What access path they use today — and what else that path also grants them.
• What keeps it where it is. Technical constraint, vendor support agreement, or simply that nobody has had the time.

The fourth column is the one that surprises people. A meaningful share of any such list turns out to be the third answer — no technical obstacle at all, just an item that has never been anyone’s priority. Those are free wins sitting in plain sight, and they are invisible until the list exists.

The third column is the one that changes the conversation. It is where somebody notices that the path serving four legacy applications also grants a route to everything else on that network segment.

What the list is actually for

With it in hand, the evaluation question changes shape. It stops being “which platform is best” and becomes “which of these could front every line on this page”.

That is a far more discriminating question, it can be asked of any vendor in a first conversation rather than discovered in month three of a pilot, and it is the question Total Access Control was built to answer — an enforcement point that presents identity in the form each of these applications expects, rather than one that can only route a connection to them.

But the list comes first, and it is worth producing whatever you conclude afterwards. The organizations that handle this well are not the ones with the best platform. They are the ones who know what is on the page.

Most have never seen it on one. The reaction when they do is consistent: shorter than feared, and more important than expected.