The logical component that evaluates policy and evidence to decide whether access should be allowed, denied, constrained, or challenged.

Security-relevant device state, such as management enrollment, encryption, patch level, endpoint detection status, and current risk score.

A distinct, verifiable identity for software such as a service, container, job, or microservice. It replaces shared static credentials.

Regulation (EU) 2022/2554, the EU Digital Operational Resilience Act, applicable to covered financial entities since 17 January 2025.

Directive (EU) 2022/2555, the EU cybersecurity directive that replaced NIS1 on 18 October 2024 and is implemented through applicable national laws.

What is Device Posture?

The assessed security and management condition of a device.

What is Workload Identity?

A unique identity assigned to software workloads for authenticated and authorized service-to-service communication.

Building the Zero Trust Roadmap — Enterprise IAM and Zero Trust Architecture

1. Start With the Zero Trust Outcome

Change the Access Question

Zero Trust asks: Should this identity access this resource under these conditions right now? It does not treat internal network location as proof of trust.

Protect Resources

A protected resource can be an application, API, dataset, administrative console, or microservice. The architecture makes decisions as close to that resource as practical.

Use Multiple Signals

Decisions combine identity, device posture, resource sensitivity, behavior, environmental context, and telemetry to deliver least-privilege access.

Current NIST Context

NIST SP 800-207 is the foundation. SP 800-207A addresses cloud-native multi-cloud access, and SP 1800-35 supplies practical implementation examples.

2. Find the Implicit Trust

Thought exercise: Challenge the old boundary

A university research portal allows anyone connected to the campus VPN to download sensitive research data after a one-time password login.

Identify three sources of implicit trust in this design. Then propose one Zero Trust signal or control for each.

Use this pattern:

Implicit trust: What is accepted without sufficient evidence?
Risk: How could it be abused?
Replacement signal/control: What evidence should affect the decision?

Example answer

Implicit trust: VPN location is treated as trusted.
Risk: A compromised laptop on the VPN can reach the portal.
Replacement: Require device compliance, phishing-resistant MFA, and a resource policy that limits downloads by role and data classification.

Checkpoint: A VPN can still provide encrypted transport. It should not, by itself, authorize access to sensitive resources.

3. Map the NIST Logical Components

Policy Engine

The Policy Engine evaluates enterprise policy, risk, and telemetry. It decides whether to allow, deny, constrain, or challenge a request.

Administrator and Enforcement

The Policy Administrator turns a decision into action. The Policy Enforcement Point applies it at an application proxy, API gateway, database gateway, sidecar, or endpoint.

Evidence Sources

Policy Information Points supply evidence: identity systems, device management, endpoint security, asset inventory, SIEM, threat intelligence, and data classification.

Map One Resource First

For one high-value resource, find the enforcement point, list decision signals, assign each signal owner, and specify allow, deny, challenge, and terminate actions.

4. Example: Protect a Finance Reporting Application

Start With a Resource

Protect the finance application and its export API separately. A broad directory group and a VPN login should not automatically grant full export capability.

Collect Decision Evidence

Use identity type, MFA result, role, employment status, device management, encryption, security-update state, endpoint detection status, and device risk.

Enforce at the Right Places

Use an application proxy for the user interface and an API gateway for exports. Issue short-lived tokens with narrowly scoped permissions such as `reports.read`.

Measure Improvement

A useful outcome is fewer standing export privileges and more approved, observable, just-in-time export sessions.

5. Turn Continuous Verification Into Policy

Continuous Does Not Mean Constant Login

Continuous verification reevaluates useful evidence at meaningful decision points. A changed risk signal can trigger a proportionate response without repeatedly interrupting every user.

Four Policy Parts

Define the subject, resource and action, context, and obligation. This turns broad intent such as "secure exports" into testable access rules.

Use Explainable Decisions

Do not rely only on an opaque risk score. Keep understandable rules, decision logs, exception paths, and tests for false positives.

Use CISA for Prioritization

CISA ZTMM Version 2 uses five pillars: Identity, Devices, Networks, Applications and Workloads, and Data; three cross-cutting capabilities support them.

6. Apply the Pattern Across Hybrid Environments

On-Premises

Use an application proxy or database gateway as a PEP. Keep segmentation, but do not let subnet membership become the sole authorization decision.

SaaS and APIs

For SaaS, centralize identity and apply conditional access. For APIs, validate token audience and scopes, client identity, and rate limits at an API gateway.

Cloud-Native Workloads

Give each microservice a distinct workload identity. Authorize every service call using its identity, destination, method, and runtime context.

NIST Cloud-Native Guidance

SP 800-207A describes multi-cloud application access patterns with API gateways, sidecar proxies, and application identity infrastructure.

7. Prioritize the First 90 Days

Roadmap activity: Choose work that reduces risk

You cannot mature every pillar at once. Score candidate initiatives using four questions:

Impact: Does this protect a high-value resource or a frequent attack path?
Feasibility: Do you have an enforceable control point and usable telemetry?
Dependency: Does this enable later work, such as identity consolidation or asset inventory?
Measurability: Can you show a before-and-after outcome?

Candidate initiatives

Deploy phishing-resistant MFA for administrators.
Inventory unmanaged devices that access sensitive resources.
Add an API gateway policy for a payment API.
Replace shared service-account credentials with workload identities.
Label and restrict exports of confidential data.

Your task

Pick two initiatives for the first 90 days. For each, write:

The CISA pillar
The resource or attack path addressed
One dependency
One measurable outcome

Hint: A strong first initiative often protects privileged access or a high-value application while improving visibility for later phases.

8. Govern the Roadmap and Map Regulations Carefully

Create Shared Ownership

Zero Trust spans identity, endpoint, cloud, applications, data, privacy, procurement, risk, and audit. Assign policy owners, evidence owners, and decision rights.

Keep Evidence-Ready Artifacts

Maintain resource and identity inventories, a policy catalog, telemetry standards, exception records, review dates, and a leadership-facing metric dashboard.

NIS2 Mapping

NIS2 replaced NIS1 on 18 October 2024. It includes proportionate risk management, basic cyber hygiene, IAM, and MFA or continuous authentication where appropriate. National transposition law matters.

DORA Mapping

DORA has applied to covered financial entities since 17 January 2025. It requires documented ICT risk management protecting ICT and information assets from unauthorized access or use.

9. Check Your Roadmap Logic

Choose the best next step

A company has strong MFA but cannot identify which devices access its sensitive customer-data API. Its API gateway accepts long-lived shared service credentials, and it has no centralized logs of API authorization failures.

Which roadmap initiative is the best immediate priority?

Which initiative best establishes the foundation for Zero Trust control of the customer-data API?

Replace the corporate VPN with a newer VPN appliance.
Deploy workload identities and short-lived API credentials, add gateway enforcement, and centralize authorization telemetry.
Require all employees to change passwords every 30 days.
Place the API servers in a separate network subnet without changing identity or logging controls.

Show Answer

Answer: B) Deploy workload identities and short-lived API credentials, add gateway enforcement, and centralize authorization telemetry.

The core problem is weak, shared software identity plus missing enforcement evidence. Workload identities, short-lived credentials, API-gateway policy enforcement, and centralized telemetry directly support resource-centric, observable, least-privilege access. Network segmentation can help, but it does not replace identity-aware API authorization.

10. Review the Roadmap Vocabulary

Flip each card, then explain how the term appears in a real access decision.

Policy Engine: The logical component that evaluates policy and evidence to decide whether access should be allowed, denied, constrained, or challenged.
Policy Enforcement Point: The component that enforces an access decision near a resource, such as an application proxy, API gateway, database gateway, sidecar proxy, or endpoint agent.
Policy Information Point: A source of evidence for policy decisions, such as an identity provider, device-management system, endpoint security tool, SIEM, or data-classification service.
Device Posture: Security-relevant device state, such as management enrollment, encryption, patch level, endpoint detection status, and current risk score.
Workload Identity: A distinct, verifiable identity for software such as a service, container, job, or microservice. It replaces shared static credentials.
Least Privilege: Granting only the minimum access needed for a specific task, resource, and time period.
Adaptive Policy: A policy that changes its decision or obligations when relevant evidence changes, such as device noncompliance, elevated session risk, or a sensitive action.
Maturity Metric: An observable outcome that demonstrates improved control, such as fewer standing privileged accounts, more managed devices, or a higher percentage of APIs using short-lived workload credentials.

Key Terms

DORA: Regulation (EU) 2022/2554, the EU Digital Operational Resilience Act, applicable to covered financial entities since 17 January 2025.
NIS2: Directive (EU) 2022/2555, the EU cybersecurity directive that replaced NIS1 on 18 October 2024 and is implemented through applicable national laws.
Device Posture: The assessed security and management condition of a device.
Workload Identity: A unique identity assigned to software workloads for authenticated and authorized service-to-service communication.
Policy Engine (PE): The logical decision component that evaluates policy, risk, and telemetry.
Just-in-Time Access: Time-limited access granted only when needed, often after additional verification or approval.
Policy Administrator (PA): The logical component that turns a policy decision into a technical action, such as issuing a token or configuring enforcement.
Zero Trust Architecture (ZTA): An enterprise architecture that removes implicit trust based on network location or ownership and protects resources through explicit, context-aware access decisions.
Policy Enforcement Point (PEP): The technical component that allows, blocks, constrains, or terminates access to a resource.
Policy Information Point (PIP): A system that provides evidence used in an access decision.