Zero Trust Architecture — Trust Nobody, Verify Everything — Auth in Depth: From Passwords to Zero Trust

I. Core Principles & Philosophy of Zero Trust

"Never Trust, Always Verify": Zero Trust Architecture (ZTA) moves defenses away from static, network-based perimeters and assumes that no user or device is implicitly trusted based on their physical or network location.
Resource-Centric Security: Authentication and authorization are discrete functions continuously evaluated on a per-transaction basis before any session to an enterprise resource is established.
The Seven Tenets of ZTA:
1. All data sources and computing services are treated as resources.
2. All communication is secured regardless of network location.
3. Access to individual enterprise resources is granted on a per-session basis.
4. Access is determined by dynamic policy, evaluating the observable state of the client identity, application, requesting asset, and environmental attributes.
5. The enterprise continually monitors and measures the integrity and security posture of all owned and associated assets.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
7. The enterprise collects as much information as possible about the current state of assets and network infrastructure to improve its security posture.

Policy Decision Point (PDP): The central brain of a ZTA, which is broken down into two logical components:
- Policy Engine (PE): Uses a trust algorithm, enterprise policies, and external data to ultimately grant, deny, or revoke access to a resource.
- Policy Administrator (PA): Acts on the PE's decision by generating session-specific tokens and sending commands to establish or shut down the communication path.
Policy Enforcement Point (PEP): The gatekeeper that resides close to the resource to enable, monitor, and terminate connections between a subject and the resource.
Control Plane vs. Data Plane: ZTA separates network communications. The control plane handles access decisions and configurations between the PA and PEP, while the data plane is used strictly for the actual application/service communication flows.
Data Sources: The Policy Engine evaluates inputs from various systems, including Continuous Diagnostics and Mitigation (CDM) tools, threat intelligence feeds, SIEM systems, Identity Management databases, and enterprise PKI.

Core Approaches: ZTA can be primarily driven by Enhanced Identity Governance (basing policies on identity and assigned attributes), Micro-Segmentation (placing individual resources on heavily protected network segments), or Software Defined Perimeters (overlay networks controlled by the PA).
Deployment Models:
- Device Agent/Gateway-Based: A software agent installed on the client device coordinates connections with a gateway placed directly in front of the resource.
- Enclave-Based: Similar to the gateway model, but the gateway protects a collection of resources (an enclave or data center) rather than an individual application, which is useful for legacy systems.
- Resource Portal-Based: A single gateway portal acts as a gatekeeper for requests without requiring installed agents on client devices, making it highly flexible for BYOD (Bring Your Own Device).
- Device Application Sandboxing: Approved applications run completely compartmentalized (e.g., in virtual machines or containers) on an asset to protect them from potential host malware.

Purpose: The thought process used by the Policy Engine to grant or deny access based on inputs like the access request, subject history, asset status, resource policies, and threat intelligence.
Evaluation Methods: TAs can be criteria-based (all predefined qualifications must be strictly met) or score-based (calculating a confidence level based on weighted data sources).
Contextual vs. Singular: A singular TA evaluates each request in a vacuum, while a contextual TA tracks the subject's recent history to detect atypical behavioral patterns that may indicate a compromised account.

Discovery and Inventory: Because the Policy Engine requires deep organizational knowledge to make accurate decisions, the enterprise must thoroughly catalog all actors (subjects/users), enterprise-owned assets, and shadow IT.
Identify Workflows: Organizations must map out business processes, data flows, and associated risks to select a candidate process for initial ZTA migration (often starting with cloud-based resources or remote workflows).
Formulate Policies and Select Solutions: Define access criteria based on the workflow and choose solutions compatible with existing ecosystem constraints.
Initial Deployment & Tuning: Most enterprises will operate in a hybrid zero-trust/perimeter-based mode indefinitely. Initial deployments should run in an observation/reporting-only mode to establish baseline behaviors and tune access criteria before strictly enforcing access denials.

Subversion of the ZTA Decision Process: If the Policy Engine or Policy Administrator is compromised or misconfigured by an administrator, an attacker could grant unauthorized access or disrupt enterprise operations.
Denial-of-Service (DoS): If the PEP or PE/PA are taken offline via a DoS attack or hosting failure, legitimate subjects will be unable to access necessary enterprise resources.
Stolen Credentials and Insider Threats: While ZTA prevents unauthorized lateral movement across a network, an attacker with valid credentials can still access the specific resources assigned to that account's purview.
Network Visibility Gaps: ZTA assumes all traffic is inspected, but much of the traffic may be encrypted or opaque to layer 3 analysis tools, requiring reliance on metadata and machine learning to detect malicious patterns.