Zero trust is not a product you bought. It is seven tenets your architecture either meets or does not.
NIST defines zero trust as a paradigm where trust is never granted implicitly but must be continually evaluated. An assessment tests your architecture against the published tenets rather than against a vendor description of its own capabilities.
- 7 tenetsThe published definition of the architecture
- 6 assumptionsAbout the network a ZTA is built on
- Per sessionHow resource access should be granted
- No implicit zoneThe private network is not trusted
The tenets are the ideal goal, and NIST says so explicitly.
That single acknowledgement makes zero trust assessable rather than aspirational, and it changes how the results should be read.
- The publication states that the tenets are the ideal goal, though it must be acknowledged that not all tenets may be fully implemented in their purest form for a given strategy. An assessment therefore produces a position rather than a pass or a fail.
- That matters commercially, because zero trust is frequently sold as a binary state a product delivers. It is an architectural direction with measurable characteristics, and knowing where you sit on each tenet is more useful than a certificate would be.
- It also removes the paralysis. Organisations postpone zero trust work because full implementation looks impossible. Improving three tenets meaningfully changes the security position, and the assessment identifies which three are worth the effort in your estate.
- And it protects the budget conversation. A board asked to fund zero trust reasonably wants to know what changes. Tenet by tenet, with a current position and a target position, is an answer they can evaluate and hold you to afterwards.
Eight things an assessment establishes about your architecture.
Trust is never implicit
The paradigm is focused on resource protection and the premise that trust is never granted implicitly but must be continually evaluated. Every architecture decision either supports that premise or quietly contradicts it, and most estates contain a mixture.
Network location alone does not imply trust
Access requests from assets on enterprise owned network infrastructure must meet the same security requirements as requests from any other network. Estates that still treat the office LAN as trusted fail this tenet regardless of what else they have deployed.
Access is granted per session
Trust in the requester is evaluated before access is granted, with least privileges needed to complete the task. Authentication and authorisation to one resource does not automatically grant access to a different resource, which is where most estates diverge from the model.
Policy is dynamic, not static
Access is determined by dynamic policy including the observable state of client identity, the application or service, and the requesting asset, and may include behavioural and environmental attributes such as location, time, and reported active attacks.
Asset posture is measured continuously
The enterprise monitors and measures the integrity and security posture of all owned and associated assets, because no asset is inherently trusted. Assets found subverted or unmanaged may be treated differently, including denial of all connections.
Authentication is a cycle, not an event
A constant cycle of obtaining access, scanning and assessing threats, adapting, and continually reevaluating trust in ongoing communication. That expectation includes identity, credential and access management, asset management, and multifactor authentication.
Everything is a resource
All data sources and computing services are considered resources, and an enterprise may classify personally owned devices as resources where they can access enterprise owned resources. That framing changes what belongs inside the scope of the architecture.
Telemetry feeds the policy
The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications, and uses it to improve its security posture and to provide context for access requests. Telemetry is an input, not a report.
Six assumptions a zero trust architecture is built on.
| Assumption | What it rules out | |
|---|---|---|
| The private network is not an implicit trust zone | Treating the office LAN as safe | |
| Assets act as if an attacker is present on the network | Unauthenticated internal connections | |
| Devices may not be owned or configurable by the enterprise | Assuming managed endpoints everywhere | |
| No resource is inherently trusted | Server to server trust by network position | |
| Subject credentials alone are insufficient for device authentication | Username and password as the whole check | |
| Not all enterprise resources sit on enterprise infrastructure | Perimeter thinking for cloud services | |
| Remote subjects cannot fully trust their local network | Trusting home and public networks | |
| Assets keep a consistent posture when they move | Different rules on and off the network |
Four things that make a zero trust assessment useful.
We assess against the published tenets, not a vendor model
Seven tenets and six network assumptions, each given an evidenced position. Vendor maturity models are designed around what that vendor sells, which makes them useful for planning a purchase and unsuitable for assessing an architecture.
We look for implicit trust zones specifically
The publication is explicit that the implicit trust zone must be as small as possible for enforcement to be specific. Finding and sizing those zones is the most direct way to see where an estate departs from the model.
We accept that full implementation is not the goal
The tenets are described as the ideal goal, with the acknowledgement that not all may be fully implemented in their purest form. An assessment that treats anything short of perfection as failure produces a report nobody can act on.
We map existing investment to the tenets it supports
Most organisations have already bought several products that genuinely advance one or two tenets. Showing which ones, and which tenets remain unaddressed, usually reframes the conversation from more spending to better sequencing.
Four phases across roughly eight to twelve weeks.
- 01Weeks 1 to 3
Establish the current architecture
Where identity is decided, where policy is evaluated, where it is enforced, and what the enterprise actually knows about asset posture. The published logical components give this a structure that is comparable between estates.
- Policy decision and enforcement points identified
- Identity and asset management inventory documented
- Implicit trust zones located and sized
- Telemetry sources mapped against policy inputs
- 02Weeks 4 to 6
Assess against the tenets and assumptions
Each of the seven tenets given an evidenced position, and each of the six network assumptions tested against how the estate is actually built. The output is a picture rather than a score, since the tenets are the ideal goal.
- Position per tenet with supporting evidence
- Network assumptions tested against the design
- Contradictions identified where design fights the model
- Quick wins separated from structural work
- 03Weeks 7 to 9
Prioritise by risk and feasibility
Not every tenet is worth the same effort in every estate. Lateral movement is called out as one of the biggest challenges, so tenets that constrain it usually rank highly, but the ordering follows your architecture rather than a template.
- Tenets prioritised by risk reduction and feasibility
- Dependencies between improvements sequenced
- Existing investments mapped to tenets they support
- Target position defined per tenet
- 04Weeks 10 to 12
Roadmap and governance
A funded and sequenced plan, with a way of measuring progress that is not a vendor dashboard. Zero trust work spans years, so the measurement approach matters as much as the first tranche of changes.
- Roadmap with sequencing and owners
- Measurement approach per tenet defined
- Board level summary framed around the tenets
- Reassessment cadence agreed
Six situations that prompt an assessment.
A regulated firm asked to evidence its architecture
Supervisors and auditors increasingly ask how access decisions are made and whether network position confers trust. An assessment against published tenets is a much stronger answer than a list of products with zero trust in their marketing.
A board asking what the programme delivered
Zero trust programmes consume significant budget over several years. A position per tenet, before and after, gives a board something to evaluate that is neither a product inventory nor an assurance from the team that spent the money.
An organisation that suffered lateral movement
The publication identifies unauthorised lateral movement as one of the biggest challenges, and the tenets are designed against it. After an incident involving movement between systems, the tenets provide a structured remediation frame.
A business moving substantially to cloud services
Not all enterprise resources sit on enterprise owned infrastructure, and assets moving between environments should keep a consistent security policy and posture. Cloud migration is where perimeter assumptions break most visibly.
An operation with unmanaged and third party devices
Devices on the network may not be owned or configurable by the enterprise, and that assumption is built into the model. Estates with contractors, visitors and operational technology need policy that accounts for it rather than exceptions that bypass it.
A team whose policy cannot see device posture
Dynamic policy is supposed to include the observable state of the requesting asset. Where access decisions rely on identity alone, that is a specific and addressable gap rather than a general shortfall in maturity.
How UAE organisations describe their zero trust position.
| Feature | Assessed against the tenets | Bought a zero trust product | Perimeter architecture |
|---|---|---|---|
Position known per tenet | Evidenced | Assumed | Not applicable |
Internal network treated as trusted | No | Often still yes | Yes |
Access granted per session | Assessed | Partially | No |
Device posture in policy | Yes | Sometimes | No |
Implicit trust zone size known | Measured | Not considered | Large |
Decision and enforcement separated | Mapped | Vendor dependent | Not applicable |
Lateral movement constrained | Deliberately | Partially | Poorly |
Roadmap tied to risk | Yes | Product driven | None |
Board can evaluate progress | Tenet by tenet | By spend | Not discussed |
Effort to reach | Weeks to assess, years to build | Procurement | None |
Ask who makes the decision, who executes it, and where the log goes.
The logical components give an assessment something concrete to test, and many estates cannot answer these three questions cleanly.
- The policy engine is responsible for the ultimate decision to grant access to a resource for a given subject, and it makes and logs the decision as approved or denied. In a real estate that decision is frequently split across several systems with no single record.
- The policy administrator establishes or shuts down the communication path between a subject and a resource by issuing commands to enforcement points, and executes the decision the engine made. Where nothing performs that role, revocation tends to be theoretical.
- Enforcement points are where the tenets become real. Moving them closer to the resource is what shrinks the implicit trust zone, and the publication is explicit that the implicit trust zone must be as small as possible for enforcement to be specific.
- The components communicate on a separate control plane while application data moves on a data plane. Estates where policy and data share a path have a structural weakness that no amount of policy configuration compensates for.
Five steps, anchored on published text throughout.
- 1
Map decision, administration and enforcement
Where the ultimate access decision is made and logged, what establishes and shuts down communication paths, and where enforcement sits relative to the resources. Those three roles give the assessment a comparable structure.
- 2
Locate and size the implicit trust zones
Every area where entities are trusted to the level of the last enforcement point. The publication states the implicit trust zone must be as small as possible, so finding the large ones identifies where the architecture most departs from the model.
- 3
Assess each tenet with evidence
Resources, communication security regardless of location, per session access, dynamic policy, continuous posture measurement, dynamic and strictly enforced authentication, and telemetry feeding posture improvement. Evidence rather than self assessment.
- 4
Test the six network assumptions against the design
Whether the private network is treated as an implicit trust zone, whether unmanaged devices are accounted for, whether subject credentials alone are relied on for device authentication, and whether posture travels with assets that move.
- 5
Sequence a roadmap the business can fund
Prioritised by risk reduction and feasibility, with existing investments mapped to the tenets they already support, a target position defined per tenet, and a measurement approach that does not depend on a single vendor dashboard.
What organisations ask about zero trust.
Fifteen questions that reveal your real position.
Trust and location
- Is the office network treated as trusted?Location alone should not imply trust.
- Do internal connections authenticate?Assume an attacker is present.
- Is traffic encrypted internally?Most secure manner available.
- How large is the implicit trust zone?It should be as small as possible.
- Do servers trust each other by subnet?No resource is inherently trusted.
Access decisions
- Is access granted per session?Not once per login.
- Does one resource grant imply another?It should not.
- Does policy use device posture?A named policy input.
- Is MFA in place for enterprise resources?An expected component.
- Is trust re-evaluated during a session?A constant cycle.
Visibility
- Do we measure asset posture continuously?All owned and associated assets.
- Can we deny an unmanaged device?A documented option.
- Does telemetry feed policy?Not just reporting.
- Is every access decision logged?The engine makes and logs it.
- Can we revoke a live session?The administrator executes it.
Ask whether a request from your office network is treated differently from the same request elsewhere.
If it is, network location is still conferring trust, and that is the second tenet. It is also the most common place an estate departs from the model.
Related Services
Explore more solutions that work great with this service
Entra Conditional Access
The control that decides who reaches your data
Entra Global Secure Access
Internet Access, Private Access and tenant restrictions
IT Risk Assessment
A short register with an owner against every risk
Endpoint Security
Defender for Endpoint and Intune managed
Microsoft Cloud PKI
Retire the certificate server, NDES and the Intune connector
Privileged Access Audit
Every privileged path, not just the admin list
Network Monitoring NOC
24/7 NOC monitoring with named engineers
ATT&CK coverage assessment
Which adversary behaviours would go unnoticed today.