Zero-Trust Security Architecture

On this page

Zero-trust architecture replaces implicit trust with explicit policy decisions enforced near enterprise resources. It requires joined identity, device, workload, network, data and telemetry design.

Decide which resources and access paths require stronger policy first, then establish the identity and telemetry foundation that supports those decisions. Zero trust is not a single architecture or product stack; it is a coordinated control model.

Architecture should state who controls policy, which signals influence access, where enforcement occurs, how sessions are re-evaluated and how the enterprise responds when signals or control services fail.

MENTARA uses NIST SP 800-207 for the logical policy model, NIST SP 800-207A for cloud-native access-control patterns and the NIST Cybersecurity Framework 2.0 to connect architecture with governance, protection, detection, response and recovery.

For a priority resource, explain how a user or workload proves identity, how context affects authorization, where policy is enforced and who owns an exception.

Control domains should share identity, resource and policy context. Separate tools without common ownership and event correlation leave gaps between authentication, authorization and response.

Identity and policy services become critical dependencies. Define availability, latency, caching and recovery for each enforcement path. A fail-open design preserves access but expands risk; fail-closed preserves control but can stop a business service. The decision should reflect resource consequence, emergency operation and audit requirements.

• Lifecycle and federation
• Strong authentication
• Privilege elevation
• Workload credentials
• Managed identity
• Posture and integrity
• Configuration policy
• Isolation and remediation
• Resource-focused segmentation
• Encrypted communication
• Session context
• Continuous re-evaluation
• Action-level authorization
• Gateway and service enforcement
• Token validation
• Transaction controls
• Classification
• Purpose and attribute controls
• Encryption and masking
• Export and loss controls

Control domains should share identity, resource and policy context. Separate tools without common ownership and event correlation leave gaps between authentication, authorization and response.

• Lifecycle and federation
• Strong authentication
• Privilege elevation
• Workload credentials
• Managed identity
• Posture and integrity
• Configuration policy
• Isolation and remediation
• Resource-focused segmentation
• Encrypted communication
• Session context
• Continuous re-evaluation
• Action-level authorization
• Gateway and service enforcement
• Token validation
• Transaction controls
• Classification
• Purpose and attribute controls
• Encryption and masking
• Export and loss controls

• Policy definitions and changes have accountable owners and review.
• Signals used for decisions have integrity and freshness expectations.
• Human and workload credentials are issued, rotated and revoked through governed lifecycle.
• Enforcement points protect actions and resources, not only network entry.
• Exception and emergency access have scope, evidence, expiry and review.
• Policy and identity service failures have explicit continuity decisions.
• Telemetry supports access assurance and incident investigation.
• Legacy implicit-trust routes are tracked to retirement.

• Priority resources and actions are classified.
• Policy decision and enforcement components are explicitly designed.
• Identity, posture and risk signals have trusted owners.
• Control availability and failure behaviour match business consequence.
• Workload identities receive the same lifecycle discipline as people.
• Exceptions and emergency access are bounded and reviewed.
• Telemetry links decisions, access and response.
• A roadmap retires legacy implicit trust and duplicate controls.