Zero trust, pragmatically: an identity-first sequence

On this page

Zero trust does not begin with a product purchase. It begins by removing implicit access decisions and giving every user, device, workload and resource an accountable policy owner.

Traditional perimeter models assume that location carries trust. Modern enterprises operate across cloud services, remote access, partners, managed devices, unmanaged devices and machine identities. The defensible boundary is the resource and the policy decision governing access to it.

An identity-first sequence creates the control foundation used by every later stage: authoritative identities, strong authentication, lifecycle management, conditional access and auditable privilege. Device, network, workload and data controls then add context and enforcement without creating parallel identity systems.

MENTARA uses NIST SP 800-207 for the core policy-decision and enforcement model, NIST SP 800-207A for cloud-native access paths and the NIST Cybersecurity Framework 2.0 to connect access-control design with governance and operational response.

Zero trust is an operating model for access decisions. Fund the policy, identity, telemetry and ownership changes together; purchasing isolated controls leaves implicit trust intact.

Define trusted sources for employees, contractors, partners, customers, devices and workloads, including joiner, mover and leaver events.

Apply phishing-resistant methods where consequence demands it and design recovery so it does not become a bypass.

• Priority identities under lifecycle control
• Priority resources under explicit policy
• Privileged paths using strong authentication
• Workload identities with managed credentials
• Policy failures and bypass routes
• Access denials requiring correction
• Exception age and expiry
• Time to revoke access
• Authentication and policy availability
• Decision latency
• Incident containment actions
• Break-glass use and review
• User journey completion
• Support demand by control
• Owner acceptance
• Legacy trust dependencies retired
• An executive risk owner and accountable control owners are named.
• The programme prioritizes resources and access paths by consequence.
• Human and workload identity lifecycles are governed.
• Authentication recovery and emergency access do not create hidden bypasses.

Define trusted sources for employees, contractors, partners, customers, devices and workloads, including joiner, mover and leaver events.

Apply phishing-resistant methods where consequence demands it and design recovery so it does not become a bypass.

Replace standing broad access with role, attribute or policy-based access and time-bounded elevation.

Classify applications, APIs, data and infrastructure by consequence, exposure and dependency.

Sequence by risk and dependency rather than attempting universal rollout. Priority paths often include administrator access, remote access, sensitive data, production systems, third-party access and machine-to-machine credentials.

A zero-trust programme creates friction when policy, user journeys and service operations are designed separately. Every control change should identify affected journeys, service dependencies, support ownership and fallback. Break-glass access needs stronger evidence and review, not permanent bypass.

Exceptions should record business reason, scope, compensating control, accountable approver and expiry. Telemetry should demonstrate that policy and enforcement continue to operate as designed. Security teams own risk standards; resource owners accept access decisions; identity and platform teams operate shared controls; a named delivery owner coordinates dependencies and escalation.

• An executive risk owner and accountable control owners are named.
• The programme prioritizes resources and access paths by consequence.
• Human and workload identity lifecycles are governed.
• Authentication recovery and emergency access do not create hidden bypasses.
• Policy decisions use trusted identity, device, resource and risk signals.
• Enforcement exists near applications, APIs, workloads and data.
• Exceptions have scope, compensating control, approver and expiry.
• Telemetry supports control assurance, incident response and continuous improvement.