identity security Archives

Reviewed: 13 September 2026 · Next review: 13 December 2026
Author: Ozlin Info Editorial Team · Human review: Lin (accountable human); Codex assisted

Zero trust is not a product, a VPN replacement or a requirement to interrupt people with a new login prompt every few minutes. It is an architecture and operating approach that removes implicit trust based only on network location, device ownership or organisational affiliation.

NIST SP 800-207 defines zero trust around users, assets and resources. Authentication and authorisation occur before a session to a protected resource is established, and policy decisions use available evidence rather than treating “inside the network” as sufficient proof (NIST SP 800-207).

ASD now places zero trust within its modern defensible architecture guidance alongside layered architecture and secure-by-design practices. Its foundations describe three principles: never trust, always verify; assume breach; and verify explicitly (ASD — Foundations for modern defensible architecture).

Start with the resource and business decision

A weak zero trust programme begins by buying tools. A stronger one begins by identifying a business resource and writing the access decision that must be enforced.

For example:

Finance records may be accessed by a current finance worker using an approved account and compliant managed device for an authorised task. High-risk sessions require stronger evidence or are denied. Privileged changes use a separate role and are logged.

That statement exposes the required capabilities: reliable identity, device information, resource ownership, policy, enforcement, logging, exception handling and recovery. It also gives the organisation something testable.

Do not try to transform every system at once. Select a workflow where the resource, users, risks and dependencies are understood. Common pilots include privileged administration, contractor access, a cloud application containing sensitive data or an internal application currently reachable by a broad network group.

Build prerequisites before dynamic policy

Zero trust decisions are only as reliable as their inputs. Establish:

an inventory of important resources, data and services;
named business and technical owners;
unique human, workload and device identities;
controlled account lifecycle and prompt removal of stale access;
device registration and meaningful posture signals where appropriate;
data classification that can influence access decisions;
central policy and change control; and
logs that allow a decision to be reconstructed.

If a directory contains shared accounts, devices cannot be identified and no one owns the application, a highly dynamic policy may add complexity without adding assurance.

Verify explicitly without creating permanent friction

Explicit verification means using evidence appropriate to the requested action. Evidence can include:

identity and authentication strength;
device identity, management and security posture;
requested resource and action;
user, service or workload role;
location, network and time as contextual signals—not sole proof;
recent risk events or impossible behaviour;
data sensitivity; and
session and transaction risk.

Phishing-resistant MFA is valuable for high-impact access, but zero trust is larger than MFA. Likewise, conditional access is not useful if emergency accounts, service identities, API keys and legacy protocols bypass it.

Good design reduces unnecessary prompts by reusing strong, current evidence and raising requirements when risk or consequence changes. It should remain possible to explain why access was allowed, denied or escalated.

Enforce least privilege at several layers

Least privilege should cover people, administrators, applications, machines and automated agents. Review both standing access and what can be requested temporarily.

Useful controls include:

role or attribute-based access tied to a defined job;
just-in-time elevation for high-impact administration;
separate routine and privileged identities;
workload identities instead of embedded shared secrets;
resource-specific application and API permissions;
approval and logging for exceptional access; and
automatic expiry where the business need is temporary.

Micro-segmentation can reduce lateral movement, but it is one possible capability—not the definition of zero trust and not mandatory in the same form for every environment. NIST SP 800-207A shows how cloud-native access can focus on application and service identity in addition to network controls (NIST SP 800-207A).

Design monitoring, resilience and exceptions together

Policy engines, identity providers, device services and enforcement points become critical dependencies. Plan what happens when one is unavailable or supplies stale information. A zero trust programme that locks out every responder during an incident is not resilient.

Document:

high-availability and recovery requirements;
protected emergency access with independent monitoring;
safe behaviour when a dependency is unavailable;
alert ownership and expected response;
policy versioning and rollback;
how false denials and false allowances are investigated; and
how compromised identities or devices are revoked quickly.

“Assume breach” means designing so one compromised account or device does not automatically reach every resource. It does not mean assuming every employee is malicious or blocking work without evidence.

Migrate in measurable increments

A practical sequence is:

Discover: map the selected workflow, resources, identities, data and current trust assumptions.
Define: write the intended access rules, evidence, exceptions and owners.
Observe: collect data without blocking to identify unexpected dependencies and policy errors.
Pilot: enforce for a limited population with support and rollback available.
Validate: test expected access, denial, elevation, revocation, outage and recovery cases.
Expand: add resources only after the operating model works.

Useful measures include:

Measure	Evidence
Resource coverage	Important resources with named owners and explicit policy
Identity hygiene	Shared, dormant and excessive accounts removed
Privilege exposure	Standing high-impact access converted or justified
Revocation	Time to remove access across connected systems
Decision quality	Sampled allow/deny decisions supported by expected evidence
User impact	Failed legitimate access, support effort and workaround attempts
Resilience	Successful identity/policy outage and emergency-access exercise

Do not claim that a drop in breaches proves the zero trust programme caused it. Security incidents are sparse, affected by exposure and detection, and not a clean single-control metric.

Treat legacy systems as explicit risk

Some systems cannot consume modern identity, device or workload signals. Record the limitation, business need, compensating controls, monitoring, owner and retirement or upgrade date. A network gateway may provide a temporary policy boundary, but it does not magically give the legacy application resource-level authorisation.

Use current ASD modern defensible architecture guidance rather than the obsolete “DSD” wording in the original article. Also avoid saying that zero trust itself proves Privacy Act, APRA, ISO or other compliance. It may support control objectives; applicability and compliance require separate assessment and evidence.

For help mapping an identity, website, cloud or administration workflow into a scoped access-control roadmap, see Ozlin Info's cybersecurity services or contact Ozlin Info.

General-information disclaimer

This article provides general technical information only. It is not architecture, legal, privacy, regulatory or compliance advice and does not define a complete zero trust implementation. Appropriate policy and controls depend on the organisation, data, systems, users, risks and obligations.

Limitations: Zero-trust migration depends on legacy constraints, identity and device signals, architecture, user impact, funding and measured tests. These steps do not guarantee security or compliance.

AI-assistance disclosure

AI tools assisted with source discovery, outlining and copyediting. A human reviewer must verify each source, architectural statement, service claim and publication decision before release. No security or compliance outcome is guaranteed.