Zero Trust Is Only as Narrow as Your Entitlements

“Every request goes through the policy engine now, so over-broad access no longer matters.”

Let me stop you before that becomes the closing slide.

Zero trust is only as narrow as your entitlements.

A policy engine decides.

Its answer depends on its inputs.

In the zero-trust design most organizations actually build, the heaviest input is the identity and what that identity has been assigned.

Evaluate an over-broad grant once and you get an over-broad answer.

Evaluate it on every request and you get the same over-broad answer, faster and more often.

With better logging.

That’s still the grant you made.

Per-request evaluation fixes a real problem.

It stops a network location, or a login that happened hours ago, from standing in for a current decision.

It does nothing to the list of things the identity was allowed to do in the first place.

Frequency is not scope.

Your engine controls how often an entitlement is checked.

Your inventory controls what a stolen credential can reach.

Different mechanisms.

Different properties.

Keep them apart.

1. “But Every Request Is Re-Evaluated.”

Yes.

Re-evaluated against what?

NIST SP 800-207, published in August 2020, names three approaches to building a zero-trust architecture.

One of them is enhanced identity governance.

In it, enterprise resource access policies are based on identity and assigned attributes as the primary driver.

Device used, asset status and environmental factors adjust the final confidence calculation.

They adjust it.

They do not replace it.

That is the design working as intended.

It also means the engine is only as discriminating as the attributes you hand it.

If an identity carries a capability it has no business holding, the engine is not wrong to grant it.

It is doing its job.

A correct evaluation of an incorrect entitlement is a correct grant of incorrect access.

Nothing in the check can notice that the assignment was too generous, because the assignment is the premise.

CISA’s Zero Trust Maturity Model, version 2.0 from April 2023, puts this in its Identity pillar.

At the Traditional stage, access management is “permanent access with periodic review.”

At the Optimal stage, it is automated access that is just-in-time and just-enough, tailored to individual actions and individual resource needs.

Notice what changes between those two rungs.

Not the frequency of the check alone.

The size of what is granted.

A maturity model that moved only the check rate would have skipped half its own ladder.

2. “But Device Posture and Behaviour Feed the Decision Too.”

They do, and they should.

The UK’s National Cyber Security Centre describes the ZTNA mechanism plainly: a policy engine evaluates signals about the identity, security posture and behaviour of users and devices to decide whether a request should be authorised.

It groups those signals into four categories.

User identity. Group membership, authentication strength.

Device identity. A cryptographically bound identifier, often hardware-backed.

Device health. MDM compliance, an EDR risk score.

User behaviour. Login pattern, location, anomalous activity.

NCSC’s reason for combining them is worth quoting: “no individual signal is perfect, but combining signals increases assurance and reduces reliance on any single control.”

Good.

Now look at what each signal is asking.

Is this the expected person?

On an expected device?

In a healthy state?

Behaving the way they usually behave?

Every one of those questions is about whether the subject is who and what it claims to be.

None of them asks whether this subject should hold this capability.

A request that passes all four signals carries the full entitlement through the gate.

That is what passing means.

Posture and behaviour signals can deny a suspicious request.

They can cut off a session that goes strange.

They cannot tell a legitimate-looking user that their standing access to an administrative tool was a mistake, because from the engine’s side it wasn’t.

It was an attribute.

3. “But Every One of Those Users Passed MFA.”

So did the attacker.

In July 2020, attackers phished remote Twitter employees through a fake internal VPN login page.

They relayed the typed credentials and a real-time two-factor code to the legitimate system within seconds.

Authentication succeeded.

It was supposed to.

The factor was real.

It was just being presented by someone else.

NIST SP 800-63-3 defines a relying party precisely: it relies on the results of an authentication protocol to establish confidence in the identity or attributes of a subscriber.

Confidence in identity.

Not a ruling on entitlement.

Once the relying party is confident, the attributes attached to the identity decide what happens next.

And what happened next is the whole incident.

The compromised accounts reached an internal agent tool.

It let its holder change account-level settings on other users’ accounts, including the confirmation email.

Including high-profile verified accounts.

Bloomberg’s reporting found that as many as 1,500 Twitter employees and partners had standing access to that tool.

Read that number slowly.

The breach began as credential phishing.

Its blast radius was set by how many standing grants of a powerful capability existed before the phishing started.

The phishing chose which door.

The entitlement inventory decided how many doors there were.

A per-request engine in front of that tool would have asked, on every request, whether this authenticated employee held access to the agent tool.

The honest answer, for up to 1,500 identities, was yes.

4. “But Each of Those Grants Was Approved.”

Probably.

That is exactly the problem.

Approval is a per-request control.

Somebody with authority looks at one request, judges it reasonable, and signs.

A good exception process makes that decision visible and attributable to a named approver.

It does not refuse the access.

It records who accepted the risk.

What no approval workflow asks is the aggregate question.

How many people should hold a capability that can act on other users’ accounts?

None of the 1,500 grants to Twitter’s agent tool had to be wrong on its own.

Each could have had a plausible reason.

A support role.

A partner integration.

A temporary need that became permanent because nobody came back for it.

The danger lived in the total, and the total was nobody’s approval.

The friction that feeds this is ordinary.

New hires wait roughly six days for full productive access, and a blocked employee has two choices: wait in the queue or escalate for an exception.

Every exception that succeeds teaches the organization that the exception path is the fast path.

Access granted under time pressure is rarely revisited with the same urgency once the pressure passes.

That is how a population of individually defensible grants becomes an indefensible population.

No individual grant has to be wrong for the total to be dangerous.

5. “But We Run Access Reviews.”

Then look at who is doing them, and with what time.

Microsoft’s access reviews assign the work to specified reviewers, group owners, or the users themselves in self-review.

The reviewer is usually a resource owner or a manager.

Their review competes with their actual job.

They want it to take five minutes.

The process wants a considered judgment on every line.

Those are not the same budget.

Enterprise Strategy Group/Omdia research put numbers on the strain.

51% of IT and security leaders flagged reviewing and approving user access as a source of problematic manual work.

49% said the same of employee provisioning and deprovisioning.

52% said it of third-party account provisioning.

And the load is growing, not settling.

80% of organizations said the scope of their access reviews increased in the past year.

82% expect it to expand again over the next two years.

A growing list against a fixed time budget has one stable outcome.

The reviewer approves what they are shown.

That is not negligence.

It is arithmetic applied to a calendar.

A rubber-stamped review then feeds the policy engine a freshly certified entitlement, which the engine faithfully enforces on every request until the next rubber stamp.

The review certified the grant. The engine re-grants it. Neither one narrowed it.

The residue is measurable.

Varonis and Trustle research, aggregated by Orchid Security, reports that 44% of organizations have more than 1,000 orphaned accounts.

64% in financial services.

79% in healthcare.

It estimates that 26% of all accounts may be stale, unused for more than 90 days, and reports figures as high as 90% in some individual organizations.

Then the part that matters here: it cites Trustle data that 27% of cloud breaches in 2024 involved misuse of dormant credentials.

A dormant account that was never disabled is, to an identity-centric engine, a valid identity with valid attributes.

The engine does not know the person left.

It knows what the directory tells it.

6. “But the Governance Tier Costs Far More Than the Product We Already Bought.”

It does.

That is worth saying out loud, because it explains a lot of zero-trust programmes that stopped at sign-in.

Okta’s Workforce Identity starts at $6 per user per month for SSO and basic MFA.

Lifecycle management and access governance appear at the Essentials tier, $17 per user per month, with a $1,500 minimum annual contract.

Microsoft sells the stack in pieces.

Entra ID P1 is $7 per user per month.

P2 is $10.

Entra ID Governance is a further $7 per user per month, and it requires a P1 or P2 base.

Access certifications, entitlement management with separation-of-duties checks, and lifecycle workflows live in that governance layer, not in the base subscription.

Do the arithmetic yourself.

On Microsoft, P1 plus Governance is $7 + $7 = $14 per user per month. P2 plus Governance is $10 + $7 = $17.

On Okta, moving from SSO to Essentials adds $17 − $6 = $11 per user per month.

For a 1,000-person workforce, that is $11 × 1,000 × 12 = $132,000 a year more than the sign-in tier, before anyone has reviewed a single entitlement.

Those are list prices from each vendor’s pricing page, and they move.

The structure is the durable part.

Sign-in is sold separately from knowing what sign-in unlocks.

So yes, an organization can buy a ZTNA product, wire it to SSO and MFA, and have a working per-request engine sitting on an entitlement inventory nobody is licensed, staffed or scheduled to prune.

That is a real architecture.

It is not a narrow one.

And buying the tier is only half the bill.

The licence makes a review campaign possible to run.

It does not supply the reviewer hours, and the Omdia figures say those hours are the constraint that is getting worse.

For scale, IBM’s 2025 Cost of a Data Breach research puts the global average breach at $4.44 million and the US average at $10.22 million, with an average lifecycle of 241 days.

Those figures cover breaches broadly, not IAM failures specifically.

But 241 days is a long time for an unrevoked credential to sit open, and the comparison to a governance line item is not the flattering one.

7. No, This Does Not Mean Per-Request Evaluation Is Pointless

Before somebody drafts the rebuttal.

Per-request evaluation removes network location as a trust input.

That matters.

A request from inside the office is no longer legitimate by postcode.

Device and behaviour signals can end a session that turns suspicious.

A continuously evaluated identity can lose access mid-session in a way a VPN tunnel never could.

Keep all of that.

The claim here is narrower.

The check cannot narrow an entitlement that was granted too broadly.

It evaluates what it is given.

If you give it 1,500 identities that can reassign any account on the platform, it will very carefully confirm, request by request, that each of them may.

That is not a failure of zero trust.

It is zero trust reporting your inventory back to you.

8. What You Should Actually Do

Inventory standing access to every tool that can act on other users’ accounts or data. Support consoles, account-recovery tools, admin panels, bulk-export functions.

Count the holders.

Then set a ceiling on that population and enforce it.

A number, owned by someone, checked on a schedule.

Suppose, purely as an invented illustration, you cut a 1,500-holder tool to 20. The count of identities whose compromise reaches it drops by 1,500 − 20 = 1,480. The phishing campaign gets harder to aim, not merely harder to execute.

Make entitlement scope an input to decisions on sensitive functions, not only identity.

“This user holds the role” is one attribute.

“This action affects another user’s account” is another.

Your policy can weigh both.

Budget governance licensing and reviewer hours together.

The licence does not supply the time.

If you buy the tier and give reviewers no hours, you have paid for a faster rubber stamp.

Measure orphaned and 90-day-stale accounts every month, and disable them.

Not flag them.

Disable them.

An account that does not exist cannot be evaluated into a grant.

Treat any use of a dormant credential as a detection case in its own right.

A long-idle account that suddenly authenticates is exactly the behaviour signal NCSC’s category exists for.

Write the rule.

Route it to someone.

9. The Model Is Not Complicated.

A per-request check evaluates the entitlements it is given.

So the reach of a compromised identity is an inventory question, not a frequency question.

Vendor prices, survey percentages and incident counts are dated evidence.

The logic does not depend on any of them staying current.

Zero trust decides how often you ask. Your entitlements decide what the answer is.

Build the engine.

Evaluate every request.

Then go and count who holds what.

Cap the populations that can touch other people’s accounts.

Disable what nobody uses.

Pay for the reviewer hours as well as the licence.

Otherwise you have a policy engine that re-approves your worst grants on every request.

That isn’t least privilege.

That’s over-privilege with excellent uptime.