Zero Trust

Review scope and evidence labels

This page is a technical and governance profile of Zero Trust as a security architecture methodology. It focuses on practical architecture, control design, operational evidence and governance implications rather than treating Zero Trust as a product category.

Evidence labels used on this page:

• Official standard/guidance — based on NIST or similar official architecture guidance.
• Official documentation — based on official public-sector implementation or maturity guidance.
• Author analysis — interpretation for cybersecurity, governance, operations and architecture on this site.
• Operational pattern — a recommended pattern that must be adapted and validated in a specific environment.
• Bibliographic review pending — a topic where scientific or industry literature has not yet been curated for this entry.

Zero Trust practice is context-dependent. A meaningful Zero Trust program should be reviewed against current architecture, identity systems, endpoint posture, application criticality, data sensitivity, monitoring capability and organisational maturity. NIST SP 800-207 is treated as the primary architecture reference for this entry.

Methodology snapshot

Field	Value
Category	Security architecture methodology
Research type	Methodology
Core idea	Never rely on network location alone as proof of trust
Primary controls	Identity, device posture, least privilege, segmentation, telemetry, policy decision and policy enforcement
Main scope	Users, devices, networks, applications, workloads, data and operational processes
Primary reference model	NIST SP 800-207 Zero Trust Architecture
Maturity framing	CISA Zero Trust Maturity Model
Review status	Official guidance reviewed; local maturity assessment requires a separate environment-specific review

What Zero Trust is

Zero Trust is a security architecture approach that removes implicit trust from network location and requires explicit, contextual evaluation before access is granted. Evidence: Official standard/guidance.

It is a methodology for designing access, segmentation, telemetry and policy enforcement across identities, devices, networks, applications, workloads and data. It is not limited to a single technology or vendor. Evidence: Official standard/guidance; Author analysis.

Zero Trust is especially relevant when users, workloads, data and services are distributed across internal networks, cloud platforms, SaaS, remote access, suppliers and automated systems. Evidence: Author analysis.

What Zero Trust is not

Zero Trust is not:

• a single product,
• a VPN replacement by itself,
• a firewall rule set,
• a cloud-only strategy,
• a password policy alone,
• a marketing label for any security tool,
• a guarantee that breaches cannot happen,
• achieved merely by adding multi-factor authentication to every login.

Zero Trust should reduce implicit trust and improve control, visibility and resilience. It does not remove the need for secure engineering, patching, monitoring, incident response, backups, governance and human review. Evidence: Author analysis.

Core principles

Useful Zero Trust principles include:

Principle	Practical meaning
Explicit verification	Access decisions use identity, device state, context, policy and risk signals.
Least privilege	Users, services and workloads get only the access they need, for only as long as required.
Assume breach	Architecture expects compromise and limits lateral movement, blast radius and persistence.
Continuous evaluation	Trust decisions are reassessed as context and risk change.
Strong telemetry	Events and decisions are logged for detection, audit and improvement.
Data-centric protection	Controls follow data sensitivity, not only network topology.
Policy-driven enforcement	Policy decision and enforcement points are designed deliberately.

Evidence: Official standard/guidance; Author analysis.

Logical architecture

A simplified Zero Trust architecture separates policy decision, policy enforcement and continuous telemetry.

User / Device / Workload
          ↓
 Identity, posture and context signals
          ↓
 ┌───────────────────────────┐
 │ Policy Decision Point     │
 │ risk, identity, context   │
 └─────────────┬─────────────┘
               │ allow / deny / step-up / limit
 ┌─────────────▼─────────────┐
 │ Policy Enforcement Point  │
 │ gateway, proxy, agent,    │
 │ network, app or service   │
 └─────────────┬─────────────┘
               ↓
        Application / Data
               ↑
       Telemetry and audit

In practice, policy decision and enforcement can be implemented through several technologies: identity providers, conditional access, endpoint security, service mesh, network segmentation, application gateways, API gateways, data access controls and monitoring platforms. Evidence: Official standard/guidance; Author analysis.

Zero Trust pillars

A practical program should cover multiple domains, not only user authentication.

Pillar	Example questions
Identity	Who or what is requesting access, and how strongly is it verified?
Devices	Is the endpoint known, healthy, managed and patched?
Networks	Is traffic segmented and observable?
Applications and workloads	Are services authenticated, authorized, monitored and isolated?
Data	Is access based on sensitivity, purpose and need?
Visibility and analytics	Are decisions, anomalies and control failures visible?
Automation and orchestration	Can policy and response adapt without unsafe manual delay?

CISA’s maturity framing is useful because it prevents Zero Trust from being reduced to identity alone. Evidence: Official documentation; Author analysis.

Identity and access control

Identity is a core Zero Trust control plane, but it is not the whole architecture.

Important capabilities:

• strong authentication,
• phishing-resistant MFA where justified,
• conditional access,
• service identities,
• workload identities,
• privileged access management,
• just-in-time and just-enough access,
• lifecycle management for users and service accounts,
• access reviews,
• separation of duties,
• session risk evaluation.

The difficult part is not only authenticating a user once; it is maintaining correct access over time as roles, devices, risk and business context change. Evidence: Author analysis.

Device and workload posture

Zero Trust access decisions should consider the state of the device or workload where appropriate.

Useful posture signals:

• managed/unmanaged state,
• patch level,
• endpoint protection state,
• disk encryption,
• configuration compliance,
• vulnerability status,
• certificate or hardware identity,
• workload image or build provenance,
• container or server runtime state,
• known compromise indicators.

Posture signals should be used carefully. Weak or stale posture data can create false confidence. Evidence: Author analysis.

Network segmentation and lateral movement control

Zero Trust does not mean the network is irrelevant. It means the network is not trusted merely because it is internal.

Network controls can still be essential:

• microsegmentation,
• deny-by-default internal flows,
• identity-aware access,
• service-to-service authorization,
• controlled administrative paths,
• ingress and egress filtering,
• encrypted transport,
• monitoring of east-west traffic,
• reduction of flat network zones.

The goal is to reduce blast radius when an identity, endpoint or workload is compromised. Evidence: Official standard/guidance; Author analysis.

Applications, APIs and workloads

Applications and APIs are frequent enforcement points. Zero Trust should influence application architecture, not only perimeter security.

Design questions:

• Does the application validate identity and authorization for each sensitive operation?
• Are service-to-service calls authenticated and authorized?
• Are API tokens scoped, rotated and monitored?
• Is authorization implemented centrally or inconsistently across services?
• Can high-risk operations require step-up controls?
• Are logs sufficient to reconstruct access decisions?
• Is access to administration functions separated and monitored?

For AI-assisted or rapidly generated software, Zero Trust thinking is useful because it challenges implicit assumptions about who can call what, from where, and with which privileges. Evidence: Author analysis.

Data-centric protection

Zero Trust should eventually connect access decisions to data sensitivity.

Examples:

• classify sensitive datasets,
• restrict bulk exports,
• monitor unusual access patterns,
• apply least privilege to reports and dashboards,
• protect logs that contain personal or security data,
• define retention and deletion paths,
• encrypt and isolate high-value data,
• control administrative database access.

Data-centric controls matter for GDPR because operational systems may process personal data even when privacy is not their primary purpose. Evidence: Author analysis.

Telemetry, monitoring and audit evidence

Zero Trust depends on visibility. If access decisions, posture changes, denied attempts and unusual behaviour are not visible, the architecture cannot be evaluated or improved.

Useful evidence sources:

• identity provider logs,
• endpoint telemetry,
• network flow logs,
• application authorization logs,
• privileged access logs,
• configuration change logs,
• vulnerability and patch state,
• ticket/change evidence,
• monitoring alerts,
• incident response notes,
• policy decision and enforcement events.

Telemetry must itself be governed. Logs can contain personal data, secrets, operational details and security-sensitive information. Evidence: Author analysis.

Maturity model approach

Zero Trust adoption should be staged. A maturity model prevents the organisation from claiming completion after one tool deployment.

A practical maturity review can ask:

Area	Initial question
Identity	Are users, admins, services and workloads uniquely identified?
Devices	Do access decisions know whether devices are managed and healthy?
Networks	Are internal flows segmented and observable?
Applications	Are application-level authorization decisions explicit and logged?
Data	Are sensitive data locations known and access-controlled?
Visibility	Can policy decisions and failures be audited?
Automation	Can high-risk events trigger containment or access changes?

Maturity should be evidence-based. A slide deck is not a maturity assessment. Evidence: Official documentation; Author analysis.

Implementation roadmap

A safe Zero Trust implementation should start with discovery and high-value paths rather than attempting a single big-bang migration.

Recommended phased approach:

1. Identify critical assets, systems and data.
2. Map identities, devices, workloads and access paths.
3. Reduce obvious implicit trust and standing privilege.
4. Strengthen identity and privileged access controls.
5. Improve endpoint and workload posture evidence.
6. Segment critical services and administrative paths.
7. Add application/API-level authorization and telemetry.
8. Connect monitoring, incident response and change records.
9. Review maturity and update policies iteratively.

This roadmap must be adapted to business risk, operational constraints and existing architecture. Evidence: Operational pattern; Author analysis.

Relationship with GDPR, SBOM, GLPI and NetXMS

Related Research	Zero Trust relationship
GDPR	Supports security of processing, least privilege, access evidence and privacy-aware control design, including GDPR Article 25 and Article 32 considerations, but does not create GDPR compliance by itself.
SBOM	Helps verify software composition and supply-chain assumptions for applications and workloads.
GLPI	Can support asset, ticket, change, ownership and remediation evidence for Zero Trust implementation.
NetXMS	Can support monitoring, topology and operational visibility, but should not be treated as an identity or policy engine.

Zero Trust becomes stronger when it is connected to asset inventory, software transparency, monitoring, incident response and governance evidence. Evidence: Author analysis.

Operational use cases

Privileged administration

Administrative paths should require strong identity, controlled devices, just-in-time privilege and detailed audit. Persistent broad admin access is one of the clearest violations of Zero Trust intent. Evidence: Author analysis.

Remote access

Remote access should not simply extend the internal network. It should evaluate identity, device posture, application need and risk context. Evidence: Official standard/guidance; Author analysis.

Service-to-service communication

Workloads should authenticate and authorize each other. Internal service calls should not be trusted merely because they originate from an internal subnet. Evidence: Official standard/guidance; Author analysis.

Incident containment

Zero Trust architecture should reduce lateral movement and support rapid containment through segmentation, session revocation, privilege reduction, device isolation and policy updates. Evidence: Author analysis.

Common implementation risks

• Treating Zero Trust as a product purchase.
• Focusing only on MFA while ignoring devices, workloads, data and telemetry.
• Keeping standing privileged access.
• Assuming internal networks are safe.
• Building segmentation without asset and dependency knowledge.
• Blocking operations because access paths were not mapped.
• Generating logs without review and retention rules.
• Failing to include service accounts and machine identities.
• Leaving legacy protocols and administrative paths unmanaged.
• Using posture signals that are stale or easy to bypass.
• Claiming maturity without evidence.

Hardening checklist for a Zero Trust program

Recommendation	Reason	Verification evidence
Inventory critical assets and identities	Access policy needs real scope	Asset register, identity inventory, ownership records
Remove standing broad privilege	Reduces blast radius	Access review and privileged account report
Enforce strong authentication for high-risk paths	Reduces credential misuse risk	Conditional access policy and login evidence
Segment administrative access	Limits lateral movement	Network policy, firewall/service mesh rules, test results
Validate endpoint/workload posture	Reduces unsafe access	Posture policy and compliance report
Log access decisions	Supports audit and incident response	Identity/application/network logs
Review service accounts	Prevents unmanaged machine trust	Service identity register and rotation evidence
Tie controls to data sensitivity	Protects high-value data	Data classification and access matrix
Test failure modes	Avoids unsafe bypasses	Tabletop, access-denial and incident containment test records
Review maturity periodically	Prevents stale architecture	Maturity assessment and improvement backlog

Governance and compliance relevance

Zero Trust can support governance by making access decisions explicit, reviewable and evidence-based. It can support compliance discussions, but it should not be described as making an organisation compliant by itself.

Relevant governance areas:

• access control,
• privileged access,
• segregation of duties,
• incident response,
• audit evidence,
• system ownership,
• supplier access,
• data protection,
• change management,
• resilience,
• risk treatment.

For GDPR, the relevance is strongest around security of processing, access limitation, logging, breach detection and evidence. Zero Trust can support GDPR Article 25 data protection by design and by default when least privilege, segmentation, explicit access decisions and auditability are designed into systems from the start. It can also support Article 32 security-of-processing evidence, but it does not create GDPR compliance by itself. For NIS2-like cyber resilience discussions, the relevance is around risk management, incident handling, supply chain and operational continuity. Evidence: Author analysis.

Scientific literature review status

Scientific and industry literature is intentionally not listed until a separate bibliographic review selects relevant sources. Useful search directions include:

• Zero Trust architecture maturity,
• microsegmentation effectiveness,
• identity-centric security models,
• policy decision and enforcement architectures,
• usability and operational friction,
• telemetry and privacy trade-offs,
• Zero Trust in cloud-native systems,
• Zero Trust for operational technology,
• Zero Trust and incident containment,
• empirical studies of Zero Trust adoption barriers.

Until that review is complete, this page relies on official guidance and author analysis. Evidence: Bibliographic review pending.

Limitations and interpretation risks

• Zero Trust can be over-marketed.
• Mature implementation is multi-year for many organisations.
• Identity controls alone are insufficient.
• Incorrect segmentation can break operations.
• Poor telemetry can hide failures.
• Over-collection of logs can create privacy and governance risk.
• Legacy systems may not support modern enforcement patterns.
• Zero Trust claims need evidence, not slogans.
• Continuous evaluation must be balanced with usability and resilience.

Related research directions

This methodology profile can be extended by separate focused research entries on:

• Zero Trust maturity assessment,
• Zero Trust identity and access control,
• Zero Trust network segmentation,
• Zero Trust telemetry and audit evidence,
• Zero Trust and GDPR,
• Zero Trust and SBOM,
• Zero Trust implementation roadmap,
• Zero Trust scientific literature review.

Further research directions

Future Zero Trust research should add curated scientific and industry literature, a practical maturity checklist for small and medium environments, evidence mapping across GLPI, NetXMS and identity-provider logs, and a reusable access-path inventory template.

Privileged administration should be documented as the first high-value Zero Trust use case because it combines identity assurance, device posture, just-in-time privilege, segmentation, logging and incident-response evidence.

Further work should also compare NIST, CISA and NCSC guidance in a dedicated entry before recommending a reusable maturity model for this site’s project context.