Zero Trust Without Identity Governance Is Structural Weakness

0. Document Intent and Audience

This paper is written for:

• Security architects
• Zero Trust programme leads
• IAM and IGA architects
• CISO and security strategy advisors
• Platform and cloud engineers

It examines why many Zero Trust implementations fail to deliver meaningful security improvement — specifically when identity governance is treated as separate from Zero Trust architecture.

1. Executive Abstract

Zero Trust has become one of the most frequently cited security frameworks — and one of the most inconsistently implemented.

Organisations declare "Zero Trust" when they:

• Deploy a Zero Trust Network Access (ZTNA) product
• Implement conditional access policies
• Require MFA for VPN access
• Adopt a SASE platform

Yet many of these implementations retain:

• Standing privileged access
• Unmanaged service accounts
• Unreviewed OAuth grants
• Undetected privilege escalation
• Ungoverned machine identities

2. Zero Trust: Core Principles

2.1 Foundational Tenets

1. Never trust, always verify — no user, device, or network is inherently trusted; every access request must be authenticated and authorised
2. Least privilege access — minimise the access granted to only what is required for the specific task
3. Assume breach — design controls under the assumption that compromise has already occurred

2.2 What Zero Trust Is Not

Zero Trust is not:

• A product
• A network architecture
• A replacement for IAM
• A single implementation project
• A compliance checkbox

2.3 The Identity-Centric View

Identity is central to Zero Trust because:

• Every access decision starts with an identity
• Every compromised identity represents a potential breach vector
• Privilege determines blast radius
• Identity telemetry provides the highest-fidelity detection signals

3. The Identity Governance Gap in Zero Trust

3.1 What Is Missing

Many Zero Trust implementations focus on:

• Network segmentation
• Device posture
• MFA at the perimeter
• ZTNA for remote access

But they fail to address:

• Standing privilege (privilege granted permanently)
• Privilege accumulation (privilege builds up over time)
• Delegation governance (OAuth grants, app trusts)
• Machine identity lifecycle (service accounts, API keys)
• Access certification (periodic validation)
• Privilege escalation detection

3.2 The "Zero Trust" Paradox

This is Zero Trust at the perimeter + implicit trust inside. This is not Zero Trust.

3.3 Structural Weakness Defined

A structural weakness is a design flaw that persists regardless of operational improvements:

• Standing privilege is a structural weakness
• Ungoverned delegation is a structural weakness
• Unmanaged machine identities are a structural weakness
• Lack of continuous verification is a structural weakness

4. Identity-Aware Zero Trust Architecture

4.1 Core Components

5. Architectural Patterns

5.1 Pattern 1: Just-in-Time Privilege Elevation

Problem: Standing privileged access creates persistent blast radius.

Solution: Privilege is granted only at request time, for a defined duration, for a specific purpose.

Implementation:

• Privileged Identity Management (PIM/PAM)
• Role assignment with expiry
• Approval workflow for elevated access
• Session monitoring during elevation
• Automatic revocation after time limit
• Audit trail for all elevation events

5.2 Pattern 2: Risk-Based Authentication

Problem: Static authentication rules cannot adapt to context.

Solution: Authentication requirements adjust based on risk signals.

5.3 Pattern 3: Policy-Driven Access Control

Problem: Disparate access controls across resources create inconsistency.

Solution: Centralised policy engine enforces consistent rules.

5.4 Pattern 4: Continuous Access Evaluation

Problem: Access granted at authentication time does not adapt to changing conditions.

Solution: Re-evaluate access continuously during the session.

6. Detection and Response

6.1 Identity-Centric Detection

6.2 Response Orchestration

Response capabilities:

• Session revocation
• Privilege removal
• Credential reset
• Account containment
• Evidence preservation

7. Implementation Roadmap

8. Common Zero Trust Misconceptions

Misconception 1: "Zero Trust is a product"

Zero Trust is an architectural philosophy. Products can support it, but no single product implements Zero Trust.

Misconception 2: "We have MFA, so we are Zero Trust"

MFA is one control. Zero Trust requires least privilege, continuous verification, and assume-breach design.

Misconception 3: "ZTNA equals Zero Trust"

ZTNA provides network-level Zero Trust. It does not address identity governance.

Misconception 4: "Zero Trust eliminates the need for IAM"

Zero Trust depends on IAM. Identity is the foundation of every access decision.

9. Measuring Zero Trust Maturity

9.1 Identity Governance Metrics

9.2 Zero Trust Maturity Model

10. IdentityFirst Position

Zero Trust without identity governance is incomplete architecture.

The gap is not in network controls or MFA products — it is in:

• Standing privilege
• Delegation governance
• Machine identity lifecycle
• Continuous access verification
• Identity-centric detection

These are identity governance issues.

IdentityFirst integrates identity governance as a foundational component of Zero Trust:

• Just-in-time privilege elevation
• Risk-based continuous authentication
• Policy-driven access control
• Delegation governance
• Machine identity lifecycle management
• Identity-centric threat detection

11. Conclusion

Zero Trust has been widely adopted and widely misunderstood.

Organisations implement network controls, deploy ZTNA products, and mandate MFA — then claim Zero Trust.

But they retain standing privilege. They fail to govern delegation. They ignore machine identities. They do not continuously verify.

True Zero Trust requires:

• Identity as the control plane
• Least privilege as the default
• Continuous verification as the operation
• Assume breach as the design philosophy

Identity governance is not separate from Zero Trust. Identity governance is the foundation of Zero Trust.