Zero Trust Is Not a Product Category

“We bought the zero-trust platform, so the architecture is zero trust now.”

Let me stop you before that reaches a steering committee.

Zero trust is an access architecture. It is not a product category.

A platform can give you a gateway.

Device telemetry.

A policy engine.

Identity integration.

None of it establishes zero trust if one successful check hands a person or a workload broad access.

And then carries that trust forward.

That’s still a perimeter grant.

The perimeter is now an identity provider, or a VPN replacement, or an access broker, instead of a firewall.

Fine.

You have moved the front door.

Moving the front door does not turn every room behind it into a separately enforced boundary.

A better reception desk is still one reception desk.

NIST SP 800-207, published in August 2020, is unusually clear about this.

Zero trust is a collection of concepts.

Least-privilege, per-request decisions, in a network you treat as compromised.

A zero-trust architecture is the plan you build from those concepts.

Component relationships.

Workflows.

Access policies.

The former is a model.

The latter is an architecture.

Neither is a SKU.

1. “But the Vendor Integrates Identity, Device Posture, and Network Access.”

Good.

Those are inputs and enforcement capabilities your access architecture needs.

They aren’t your architecture by themselves.

NIST’s fourth tenet says access is determined by dynamic policy.

The observable state of the client identity.

The requesting asset.

Your application or service.

Behavioural and environmental attributes.

The seventh tenet requires you to collect current information about assets, network infrastructure and communications.

Then use it.

So identity, device posture and network access are not three stickers that confer zero trust when you put them on the same purchase order.

They are different signals and control layers.

Something has to make a policy decision about a named resource, at the time access is requested. Then something has to enforce that decision at that resource boundary.

The UK’s NCSC lists the practical signal categories for ZTNA.

User identity.

Device identity.

Device health.

User behaviour.

NIST’s enhanced identity-governance approach makes identity and attributes primary, and keeps device, asset status and environment in play.

“Identity-centric” doesn’t mean “the directory lookup did all the work.”

So your architecture question is embarrassingly concrete.

Which resource are you protecting?

Which signals can change?

Which policy consumes them?

Where does the grant stop?

If your answer is “the product knows who the user is,” that is not an answer. That is a feature brochure trying to pass a threat model.

2. “But Users Authenticate Before They Get to the Application.”

Authentication tells you that a presented identity proved a credential at a particular time.

It does not authorize every resource that identity can now see. It does not prove your credential, the device, or the session stays legitimate afterwards.

NIST’s third tenet is specific.

Access to an individual resource is granted per session.

Evaluated before the grant.

And authorization to one resource doesn’t automatically grant access to another.

That last clause is doing a great deal of work.

It is the difference between an access model and a velvet rope around a whole floor.

A credential can be phished after a session begins.

A device can pick up malware after it passed a posture check.

An account can be handed to an attacker mid-session.

No new login event.

None of this is exotic.

These are not exotic puzzles.

They are the ordinary reason a fact that was true at login cannot be treated as a permanent property of every later request.

The sixth tenet follows.

Resource authentication and authorization are dynamic and strictly enforced before access is allowed.

A continuing cycle: access, threat assessment, adaptation, reevaluation.

Your model isn’t “verify everything once, but with MFA this time.”

It is re-derive the decision, because the premises decay.

You would never say “we authenticated this service account last month, so it may administer every system forever.”

Say the same thing with a browser cookie and somehow it becomes a practical session model.

It isn’t.

It’s a durable permission built from a very short-lived observation.

3. “But the VPN Is Gone, So Implicit Trust Is Gone Too.”

No.

A VPN is one way to make a broad network-location grant.

Removing it can be a real improvement.

It isn’t proof that broad grants have disappeared.

NIST’s network premise is blunt.

Your private network is not an implicit trust zone.

Assets should behave as if an attacker is already on it.

The second tenet secures communication regardless of network location.

A request from your LAN, a remote office, a managed device or somebody’s home network does not become legitimate by originating from the preferred side of a diagram.

Through the 1990s a perimeter firewall fitted the topology.

Most assets, workers and relevant traffic sat behind one actual edge.

Your model was coherent because your boundary described reality.

Then the topology stopped cooperating.

Jon Measham’s 2001 de-perimeterization argument, the Jericho Forum’s formation in January 2004, John Kindervag’s 2010 coinage of the term, Google’s BeyondCorp paper in December 2014, that line traces the shift from an eroding boundary to an access design that treats your internal network as no more trusted than the public internet.

Replacing a bulk VPN tunnel with a ZTNA service is worthwhile when it changes the grant from “this device is on your network” to “this subject may access this resource now, under this policy.”

If it just replaces the tunnel with a broad application catalogue available after one check, you have not removed the implicit trust zone.

You’ve redecorated it.

4. “But the Policy Engine Makes the Decisions for Us.”

Excellent.

Now separate a decision from an enforcement path, before the nouns turn into fog.

NIST splits your policy decision point into a policy engine and a policy administrator.

Your policy engine makes the ultimate grant, deny or revoke decision.

It uses policy, plus inputs: diagnostics and mitigation data, threat intelligence, compliance rules, logs, enterprise PKI, identity management, a SIEM.

Its trust algorithm is the process it uses to get there.

Your policy administrator executes that decision.

It establishes or shuts down the communication path by configuring the enforcement point.

The PEP enables, monitors and eventually terminates the connection between a subject and the resource.

It carries application traffic on your data plane.

It talks to the administrator on your control plane.

These aren’t interchangeable labels for a magic cloud.

A policy engine with no PEP applying its decisions is a document.

A PEP with no current policy inputs is a rubber stamp.

And a policy administrator that cannot shut down a path has made revocation a strongly worded suggestion.

Placement matters just as much.

NIST calls the region behind the last PDP/PEP gateway the implicit trust zone.

Put one PEP at your network edge, and everything beyond it is trusted to the level of that gateway.

Move the PEP closer to a resource and the zone shrinks.

That’s your test.

Ask where the last enforced decision sits, not whether your vendor’s homepage says “zero trust” in a heroic font.

5. “But the Policy Engine Evaluates More Than a Password.”

It should.

That still doesn’t make a static decision dynamic.

Dynamic policy needs current evidence, and a point where that evidence can change the outcome.

The fifth tenet requires you to monitor and measure the integrity and posture of owned and associated assets.

The sixth requires the resulting authentication and authorization to be dynamic and strictly enforced.

A device that was compliant at boot can stop being compliant.

An EDR risk score.

A vulnerability state.

An authentication context.

An anomaly.

None of it is carved into stone because a login happened.

Which is why short sessions, explicit reauthentication rules and token-lifetime rules belong in your architecture, not in a document somebody writes after procurement.

They define when you check current state again, and when a previous grant expires.

Without them, “continuous evaluation” is a marketing adjective applied to whatever was convenient to collect at login.

NIST describes four PEP-placement models, each with a different visibility tradeoff.

A device agent and gateway observes managed endpoint state continuously.

You need an agent on every requester.

A resource portal needs no client software.

Good for BYOD and partner access.

It can only inspect assets once they connect.

You lose visibility between sessions.

An enclave gateway helps where legacy applications cannot have individual gateways, but may not protect each resource individually.

Device-application sandboxing protects a compartmentalized application rather than the whole endpoint.

Those are deployment constraints, not loopholes in the definition.

If a model cannot see a state change, your architecture has to admit what it cannot reassess, and bound the access accordingly.

6. “But Legacy Applications Cannot Do Per-Request Authorization.”

Sometimes they cannot.

That is a real constraint.

This is the objection that makes the product-category story expensive, because it demands an honest answer instead of another integration diagram.

CISA’s Zero Trust Maturity Model is direct about this.

Legacy systems often rely on implicit trust.

Access and authorization assessed infrequently, from fixed attributes.

That conflicts with adaptive trust evaluation.

A wrapper can reduce your exposure.

It cannot always turn a protocol designed around a standing trust relationship into a resource-level adaptive authorization system.

A 2025 GAO review makes the scale concrete.

Of 11 critical federal legacy systems across 10 agencies, 8 used outdated programming languages.

4 ran hardware or software the manufacturer no longer supports.

7 operated with known vulnerabilities.

Two Treasury systems were 59 and 51 years old, running COBOL and Assembly.

Agencies reported spending roughly 80% of a $100-billion-plus annual IT and cyber budget operating and maintaining what they already had, rather than modernizing it.

You are probably not exempt from that arithmetic.

So name the exception.

Isolate it, restrict what it can talk to, give it a modernization owner, and put a date on the fixed-attribute trust you are choosing to keep.

An exception you have written down is an architecture.

An exception you have not is a surprise with a maintenance window.

7. “But This Is a Public Service, So the Tenets Do Not Apply.”

For once, partly right.

NIST limits its tenets to work inside an organization, or with partner organizations. For a general public-facing resource that needs no login, the tenets do not directly apply.

You cannot strictly control requesting-asset state, and the resource intentionally accepts anonymous access.

Your public marketing site is allowed to be public.

That shouldn’t require a philosophy debate.

What does not follow is that your model stops applying the moment a request arrives from outside.

The question is whether a resource has a subject you can evaluate.

Most of the things you actually worry about do.

8. No, This Does Not Mean You Are One Purchase From an Architecture

Before somebody drafts the rebuttal: zero trust does not replace patching, key management, monitoring or general hygiene.

NIST says plainly that no enterprise eliminates cybersecurity risk.

A properly implemented ZTA reduces risk when it complements existing policy, IAM, continuous monitoring and hygiene.

Access control is a layer.

It isn’t a software-update service wearing a policy badge.

Your architecture also creates concentrated dependencies.

NIST identifies your policy engine and administrator as key enterprise components.

Resource communication depends on their approval and configuration.

A denial-of-service attack against the PEP, or the PE and PA, degrades operations across every gated resource.

So design their availability, telemetry integrity, administration and recovery as seriously as you design the resources they protect.

Assume compromise doesn’t mean pretend your policy plane cannot fail.

It means putting your policy plane inside the thing you are assuming is fallible.

That is why an actual architecture beats a product label.

It has to survive its own dependencies.

9. What You Should Actually Do

Start with protected resources, not vendors. Inventory the applications, services, data stores, administrative paths and partner-facing systems whose access has to be constrained.

Name the subject types, the resource-level actions, the current decision inputs, and the boundary that enforces each grant.

Put a PEP in front of each viable resource, or state precisely why one has to sit behind an enclave gateway or portal for now.

For every path, record what the PEP can enable, monitor and terminate; what the policy engine can evaluate; and what the administrator can configure or revoke.

“We have a policy engine” is not an architecture diagram.

Evaluate identity, device state, requested resource and session risk for every request, or for a defined short session.

Set explicit reauthentication and token-lifetime rules.

If a signal is only available at connection time, say so, and do not call the unobserved period continuous evaluation.

You do not strengthen a control by lying about its sampling rate.

Shrink the implicit trust zones your systems allow you to shrink. Managed endpoints can carry an agent and gateway.

Unmanaged or partner devices get a portal, which makes the boundary explicit and changes what you can observe. Legacy systems get isolation, restricted communications, an owner and a date.

Test the access model as an assumed-compromise model. For every resource, ask what happens after a credential is abused, after device posture changes, after a network location changes, after the policy path is unavailable.

Your answer should name a specific enforced boundary and an operational response.

Not a vendor family.

10. The Model Is Not Complicated.

Network location and a prior successful check do not prove a later request is still legitimate.

That is the durable claim.

Product capabilities, adoption percentages and the age of particular legacy systems are timely evidence, the logic does not depend on any of them staying current.

Zero trust supplies the access model: current, least-privilege, resource-level decisions under an assumed-compromised network. Your security architecture supplies the rest. Independent boundaries, contained blast radius, and explicit handling of whatever cannot yet be made dynamic.

Buy the platform if it gives you your policy inputs and enforcement points your design needs.

Then do the unglamorous part.

Place your boundaries.

Make the grants narrow.

Expire stale trust.

Isolate the exceptions.

Keep your policy plane resilient.

Otherwise you have bought a zero-trust product and kept a once-trusted architecture.

That isn’t a transformation.

That’s a very expensive sticker on the old front door.