Zero Trust Architecture MCQ 60 Tests With Answers (2026)

Incorrect·C: NIST SP 800-207

NIST SP 800-207 (August 2020, titled "Zero Trust Architecture") is the definitive federal framework for Zero Trust. It defines the core ZTA logical components (Policy Decision Point, Policy Enforcement Point, Policy Engine, Policy Administrator), the Trust Algorithm, seven ZTA tenets, and three ZTA deployment models (Device Agent/Gateway, Enclave, Resource Portal). NIST SP 800-53 is the Security and Privacy Controls catalog; SP 800-171 covers protecting Controlled Unclassified Information (CUI); SP 800-61 is the Incident Response guide.

Incorrect·A: Policy Decision Point

The Policy Decision Point (PDP) is the "brain" of the NIST Zero Trust logical architecture. It receives access requests from the Policy Enforcement Point (PEP) and evaluates them using the Trust Algorithm — integrating signals from the Identity Provider, device posture assessment, threat intelligence feeds, and behavioral analytics. The PDP outputs a grant, deny, or conditional decision. The PDP comprises two sub-components: the Policy Engine (PE, which makes the trust decision) and the Policy Administrator (PA, which instructs the PEP to execute that decision by opening or closing the access pathway).

Incorrect·D: To act as the gateway that enables, monitors, and eventually terminates the connection to a resource based on the PDP's commands

The Policy Enforcement Point (PEP) is the operational gateway in the NIST ZTA architecture — it sits between the subject (user/device) and the protected enterprise resource, and physically enforces the access decisions made by the PDP. When the Policy Administrator (part of the PDP) signals "allow," the PEP opens the connection channel; when it signals "deny" or the session risk degrades, the PEP terminates it. The PEP can be implemented as a ZTNA connector, an API gateway, a cloud proxy, or a software agent. It has no independent decision-making authority — it solely executes PDP commands.

Incorrect·C: It handles the authentication, authorization, and policy evaluation processes before allowing connections

Separating the control plane from the data plane is a fundamental ZTA architectural principle. The control plane handles all authentication, authorization, policy evaluation (the Trust Algorithm), identity verification, device posture assessment, and the issuance of session tokens or connection authorization — all before the data connection is established. Only after the control plane approves the request does the data plane open to carry the actual traffic. This separation means attackers who compromise the data channel cannot influence policy decisions, and the control plane can be hardened, monitored, and scaled independently.

Incorrect·B: A security approach that hides internet-connected infrastructure and uses software to create individualized, 1-to-1 network connections

A Software-Defined Perimeter (SDP), originally developed by the Cloud Security Alliance (CSA), is an architecture that makes infrastructure invisible to unauthorized users. Unlike a traditional firewall (which has known open ports that attackers can probe), an SDP hides internet-connected resources entirely — they have no public listening ports, so they are invisible to network scanners. Access is granted only after Single Packet Authorization (SPA) proves identity. The SDP controller then creates ephemeral, encrypted, 1-to-1 network connections between authorized subjects and specific resources — individualized tunnels that expire after the session.

Incorrect·A: By ensuring applications do not have public, open listening ports; instead, outbound connections are made to a broker

"Dark Cloud" or application cloaking is a core ZTNA security benefit. ZTNA applications do not publish public IP addresses or listen on open inbound ports accessible to the internet. Instead, the ZTNA connector deployed near the application makes an outbound connection to the ZTNA cloud broker (like Zscaler Private Access, Cloudflare Access, or Palo Alto Prisma Access). Authorized user sessions are brokered through this outbound tunnel. Because the application never opens inbound ports, it is invisible to port scanners, internet-wide probing (Shodan), and pre-authentication exploit attempts — dramatically reducing the exposed attack surface.

Incorrect·C: Dynamically adjusting access rights based on real-time attributes like location, device security posture, and user behavior

Context-Aware Access (also called Risk-Based Authentication or Adaptive Access Control) dynamically evaluates a rich set of real-time attributes before granting, modifying, or revoking access. Context signals include network location (corporate office vs. unknown country), device security posture (compliant/non-compliant), time-of-day (normal business hours vs. 3am), user behavior (normal application usage vs. bulk export), and threat intelligence (device IP on a blocklist). Unlike static role-based rules that apply uniformly regardless of risk, Context-Aware Access adjusts in real-time — it might grant full access from a managed device on a corporate network but require additional MFA and restrict to read-only access from an unmanaged device overseas.

Incorrect·D: The Identity Provider (IdP)

The Identity Provider (IdP) is the authoritative source of user identity in a ZTA. It manages the full identity lifecycle — account creation, attribute management (roles, groups, department), authentication (verifying credentials and MFA), and the issuance of identity tokens (SAML assertions, OAuth tokens, OIDC ID tokens). The Policy Engine queries the IdP to verify who is requesting access. Examples: Microsoft Entra ID (Azure AD), Okta, Google Workspace, Ping Identity. The IdP integrates with the Trust Algorithm: without a verifiable identity from a trusted IdP, no access is granted — regardless of device or network location.

Incorrect·B: Designing and operating the network as if an attacker is already present and actively trying to steal data

"Assume Breach" (one of Microsoft's three Zero Trust principles) means organizations must design, architect, and operate their security posture as if attackers have already gained a foothold — even on the internal network. This mindset shift drives critical architectural decisions: micro-segment everything (so a breached segment cannot reach others), encrypt all east-west traffic (so an internal eavesdropper cannot read data), log and monitor all traffic (because the attacker is watching and moving), and validate every access request end-to-end (because an internal IP address is not trusted). Assume Breach is the adversarial thinking that makes ZTA designs resilient.

Incorrect·A: SASE integrates ZTNA, cloud security, and SD-WAN into a unified, cloud-delivered service model

SASE (pronounced "sassy"), coined by Gartner in 2019, is a cloud-native architecture that converges multiple network security functions into a single, globally distributed cloud service. SASE integrates: ZTNA (for application access), Cloud Access Security Broker (CASB, for cloud app visibility and control), Secure Web Gateway (SWG, for internet access security), Firewall as a Service (FWaaS), and SD-WAN (for intelligent traffic routing). Zero Trust is the overarching security philosophy embedded throughout SASE. Key SASE vendors: Zscaler, Palo Alto Prisma SASE, Cisco Umbrella, Cloudflare One.

Incorrect·C: It provides real-time telemetry on device health and threat status to the Policy Decision Point

EDR (Endpoint Detection and Response) is a critical Zero Trust data source. The EDR agent on each endpoint continuously monitors device health and security events — active processes, network connections, file system changes, registry modifications, and threat detections — and streams telemetry to the Policy Decision Point (PDP). The PDP uses this real-time device health signal as input to the Trust Algorithm: if the EDR reports malware detected on a device mid-session, the PDP can immediately revoke the device's access without waiting for the user to re-authenticate. EDR feeds the "Continuous Verification" requirement of Zero Trust.

Incorrect·D: Shifting the security focus from protecting network perimeters to directly protecting the data itself through encryption, tagging, and access controls

Data-Centric Security recognizes that in a Zero Trust world — where users roam across multiple devices, the cloud stores data outside any perimeter, and attackers may be present on the internal network — the only way to truly protect sensitive data is to secure the data itself, not the network boundary around it. This means: classifying all data (public, internal, confidential, restricted), tagging data assets with metadata, encrypting data at rest and in transit (including within the internal network), applying Information Rights Management (IRM/DRM) so data remains protected even when copied to USB or emailed externally, and using DLP to prevent unauthorized data movement. The data pillar is one of the five CISA Zero Trust Maturity Model pillars.

Incorrect·B: To ensure user access privileges are dynamically updated or revoked as employees change roles or leave the organization

IAM Lifecycle Management in ZTA ensures that access entitlements remain aligned with a user's current role, responsibilities, and employment status — a critical control given that 58% of insider threats involve former employees or contractors (CERT). The lifecycle encompasses: provisioning (granting least-privilege access when hired), access reviews (quarterly/annual reviews to remove excess permissions), role changes (automatically updating access when promoted or transferred), and deprovisioning (immediately revoking all access upon departure). Without lifecycle management, users accumulate excessive permissions over time — a phenomenon called "permission creep" — which dramatically increases the blast radius of a compromise.

Incorrect·A: The process used by the policy engine to evaluate signals (identity, device, context) and determine if access should be granted

The Trust Algorithm (TA) is the decision-making process within the Policy Engine (PE) component of the PDP, as described in NIST SP 800-207. It takes as inputs: the user's identity (from the IdP), device compliance status (from MDM/EDR), threat intelligence data, behavioral analytics (UEBA), resource sensitivity classification, and the subject's requested action. The TA weighs these inputs against the organization's security policy to produce an access decision: Allow, Deny, or Conditional (e.g., allow but step up to MFA, or allow with reduced permissions). The TA continuously re-evaluates these signals throughout the session, not just at the moment of initial authentication.

Incorrect·C: Because continuous verification relies on analyzing logs to detect anomalous behavior and feed real-time data back into the Trust Algorithm

Comprehensive logging is the nervous system of Zero Trust — without it, "Continuous Verification" and "Assume Breach" are impossible to implement. Every access request, authentication event, policy decision, session activity, and data access must be logged. These logs feed the SIEM and UEBA (User and Entity Behavior Analytics) systems, which detect anomalous patterns and provide real-time signals back to the Trust Algorithm. If a user account suddenly accesses 10,000 files in 5 minutes (potential data exfiltration), the SIEM must detect and signal the PDP to revoke access immediately. Without logs, lateral movement and data theft remain invisible for months.

Incorrect·D: Zero Trust uses dynamic Attribute-Based Access Control (ABAC) in addition to roles to make real-time decisions

Traditional RBAC grants access based on static role membership: a user assigned to the "Finance" role gets all Finance application permissions, always, regardless of context. Zero Trust extends this with Attribute-Based Access Control (ABAC) — where the access decision dynamically incorporates real-time attributes: device health, location, time, behavioral risk score, data sensitivity, and the specific action being performed. A "Finance" user on a non-compliant device in an unrecognized country at 3am receives a different access decision than the same user on a compliant device in the office at 9am — even for the same resource. ABAC enables the contextual precision that Zero Trust requires.

Incorrect·B: A deployment model where users authenticate to a central gateway/portal, which then securely proxies their connection to backend resources

The Resource Portal model (one of three NIST SP 800-207 ZTA deployment approaches) presents users with an authenticated portal (typically web-based) that acts as a gateway to all corporate applications and resources. Users authenticate to the portal with strong identity verification (MFA, SSO), and the portal — acting as a reverse proxy — securely proxies requests to the requested backend resources without exposing those resources directly to the internet. Applications appear as portal links rather than direct network connections. This model is particularly suitable for browser-based applications, legacy apps, and organizations transitioning from VPN without deploying full endpoint agents.

Incorrect·A: Contextual checks (like device health, location, and MFA) prevent the attacker from utilizing the stolen password on an unapproved device

Stolen credentials are effective in a traditional perimeter model because a correct password grants VPN or network access from anywhere. Zero Trust nullifies this: even with a valid username and password, the attacker must also satisfy MFA (which they typically lack — hardware FIDO2 tokens are phishing-resistant), device posture checks (the attacker's device will fail MDM compliance and EDR health checks), location and context checks (impossible travel, unknown device fingerprint), and behavioral baselines (anomalous access patterns trigger step-up authentication or session termination). Credentials alone are insufficient to gain access in a mature Zero Trust implementation.

Incorrect·D: A non-human account used by applications to communicate via APIs; they often have excessive privileges and cannot easily use MFA, making them prime targets

Service Accounts are non-human identities used by applications, scripts, and services to authenticate to other systems, databases, and APIs for machine-to-machine communication. They present a critical ZTA challenge because: they typically have broad, static privileges that were "set and forgotten"; they cannot easily participate in interactive MFA workflows; they are often shared across multiple services (making attribution impossible); their credentials rarely rotate; and they are not subject to behavioral monitoring like human accounts. Attackers specifically target service accounts in post-exploitation phases (e.g., Kerberoasting in Active Directory). ZTA solutions: PAM (Privileged Access Management), short-lived mTLS certificates (via SPIFFE/SPIRE), and workload identity frameworks.

Incorrect·C: You cannot protect what you cannot see; therefore, organizations must discover, classify, and monitor all assets, users, and data flows

Complete asset and traffic visibility is a prerequisite for Zero Trust — you cannot apply policies to resources you do not know exist, and you cannot detect anomalies in traffic patterns you cannot see. Zero Trust requires: a real-time asset inventory (all devices, workloads, APIs, data stores); continuous network traffic monitoring (flow logs, DNS logs, proxy logs); user activity logging; and data flow mapping (understanding which service talks to which data store). This comprehensive visibility feeds the SIEM, informs the Trust Algorithm's risk scoring, and enables threat hunting. Shadow IT and unmanaged devices represent gaps in this visibility that blind the security team.

Incorrect·B: The Policy Engine (PE) and the Policy Administrator (PA)

NIST SP 800-207 decomposes the Policy Decision Point (PDP) into two distinct sub-components: the Policy Engine (PE) and the Policy Administrator (PA). The Policy Engine is the decision-making core — it runs the Trust Algorithm, evaluates all input signals (identity, device posture, threat intel, behavioral data), applies the organization's security policies, and produces a trust determination (grant/deny/conditional). The Policy Administrator is the communication component — it translates the PE's decision into operational instructions, communicating with the Policy Enforcement Point (PEP) via a secure control channel to open or close the session pathway to the requested resource.

Incorrect·A: A protocol where both the client and the server cryptographically authenticate each other's certificates before establishing a connection

Standard TLS is one-directional: the server proves its identity to the client via a certificate (HTTPS). Mutual TLS (mTLS) extends this to bidirectional authentication — both the client and the server must present valid, trusted X.509 certificates to each other before the TLS session is established. In Zero Trust, mTLS is the standard for service-to-service (east-west) authentication in microservices architectures: each service has its own certificate-based identity, and no service accepts connections from services that cannot prove their identity. SPIFFE/SPIRE are the standards for managing these workload certificates at scale. mTLS eliminates reliance on network location as an implied trust signal.

Incorrect·C: By using a Service Mesh to enforce mTLS and strict access policies for "east-west" traffic between individual containers

Kubernetes and microservices architectures generate enormous volumes of dynamic east-west (intra-cluster, container-to-container) traffic. Applying traditional perimeter firewall rules to thousands of ephemeral pods is operationally impossible. A Service Mesh (Istio, Linkerd, Consul Connect) solves this by injecting lightweight proxy sidecars alongside each container. These sidecars enforce mTLS for all inter-service communication (providing mutual authentication and encryption), apply fine-grained authorization policies (Service A can call Service B on GET /api but not POST /admin), and generate detailed telemetry (request rates, latency, error rates) for observability. This delivers Zero Trust principles at the workload identity level.

Incorrect·D: It overcomes the "first packet problem" by silently dropping all traffic unless the sender provides a cryptographically signed packet, making the PEP invisible to port scanners

Single Packet Authorization (SPA) solves the fundamental weakness of traditional network access: any server listening on an open port can be probed and attacked before authentication. In SPA, the SDP gateway silently drops ALL incoming packets by default — including TCP SYN packets and ICMP pings. The only exception: a single specially crafted, cryptographically signed UDP packet (the SPA packet) that encodes the sender's identity, timestamp, and signed HMAC. Only upon validating this SPA packet does the gateway temporarily open a specific port for that sender's IP. To external scanners (Shodan, Nmap), the server appears completely closed and portless — making it effectively invisible before authentication.

Incorrect·B: Identity, Devices, Networks/Environments, Applications/Workloads, Data

The CISA Zero Trust Maturity Model (ZTMM), published in April 2023, organizes Zero Trust capabilities into five pillars representing the key elements of an enterprise security environment: (1) Identity — who is trying to access; (2) Devices — what device is attempting access; (3) Networks/Environments — the channels through which data travels; (4) Applications/Workloads — the services being accessed; (5) Data — the asset being protected. Each pillar has four maturity levels: Traditional, Initial, Advanced, Optimal. The model also defines three cross-cutting capabilities: Visibility & Analytics, Automation & Orchestration, and Governance.

Incorrect·A: Granting elevated privileges to a user for a strictly limited period of time to complete a specific task, then automatically revoking them

Just-In-Time (JIT) access is a privileged access management technique that implements least-privilege at a temporal dimension: instead of granting standing (always-on) privileged access, JIT provisions elevated permissions only when needed for a specific task and for a defined, minimal time window, then automatically revokes them when the window expires or the task is complete. A database administrator who needs to run an emergency maintenance script might receive 15-minute database admin access — after that, the privilege is gone. JIT dramatically reduces standing privileges, shrinks the attack surface from credential theft (there are no standing privileged credentials to steal), and creates a clear audit trail of all privileged activity.

Incorrect·C: Open-source standards and toolchains used to securely issue and manage short-lived cryptographic identities for dynamic workloads (like containers)

SPIFFE (Secure Production Identity Framework for Everyone) is an open-source standard (CNCF project) that defines how dynamic workloads (containers, microservices, VMs, functions) identify themselves cryptographically. It provides a SPIFFE Verifiable Identity Document (SVID) — an X.509 certificate or JWT token — to each workload. SPIRE (SPIFFE Runtime Environment) is the reference implementation of SPIFFE: it is the server-and-agent system that attests workload identity (verifying what the workload is, not just who deployed it), issues SVIDs, and manages their rotation. Together, SPIFFE/SPIRE enable mTLS and workload identity in dynamic cloud-native environments where IP addresses are meaningless.

Incorrect·D: A reverse proxy terminates the connection and inspects Layer 7 traffic before forwarding; routed ZTNA connects users directly at Layer 3/4 via a local agent

ZTNA deployments have two primary architectures: Reverse Proxy (Clientless ZTNA) — the ZTNA gateway terminates the user's HTTPS connection at Layer 7, inspects the full application payload, and makes a new connection to the backend application. This works for browser-accessed web applications without a client agent, provides deep application inspection, and is simpler to deploy. Routed/Agent-based ZTNA — a lightweight ZTNA agent on the endpoint establishes a Layer 3/4 encrypted tunnel directly to the ZTNA connector near the application, supporting all traffic types (TCP/UDP), including thick-client applications, SSH, and RDP that are not browser-accessible.

Incorrect·B: Using machine learning to continuously analyze passive traits (like typing cadence, mouse movements, and gait) to implicitly verify identity post-login

Behavioral biometrics uses machine learning to build a unique behavioral fingerprint for each user based on passive, transparent signals: typing rhythm (keystroke dynamics — timing between keystrokes), mouse movement patterns (trajectory, speed, click pressure), touchscreen gestures (swipe angle, pressure, speed), and even cognitive patterns (navigation sequences within applications). Unlike active MFA (which interrupts the user), behavioral biometrics operate invisibly post-authentication and continuously — if the behavioral profile suddenly deviates (e.g., the account has been passed to an attacker who types differently), the system can step up authentication or revoke the session without disrupting legitimate users.

Incorrect·A: The PDP is a single point of failure; if compromised or knocked offline, legitimate access halts, or the attacker gains total control over all network access policies

The PDP is the crown jewel of a Zero Trust architecture — it controls all access decisions across the entire organization. This centrality creates a critical Single Point of Failure (SPOF) and a high-value attack target. If the PDP is taken offline (DDoS, infrastructure failure), all access requests fail (fail-close) — legitimate users cannot work and the organization grinds to a halt. If the PDP is compromised (an attacker gains admin access), they can modify policies to grant themselves access to all resources. Mitigations: highly available PDP deployment (geo-redundant), strict privileged access controls on PDP administration, continuous integrity monitoring of PDP policy state, and PAM-gated administrative access.

Incorrect·C: By deploying an Identity-Aware Proxy (IAP) or secure gateway in front of the legacy app to handle modern authentication before passing traffic to the app

Legacy applications (older ERP systems, proprietary internal tools, mainframe interfaces) often cannot be modified to support modern authentication protocols (SAML 2.0, OIDC, OAuth 2.0). An Identity-Aware Proxy (IAP) — like Google's IAP, Cloudflare Access, or Palo Alto Prisma Access's App Connector — acts as a Zero Trust wrapper: users authenticate to the IAP using modern MFA and SSO protocols, and the IAP performs protocol translation to authenticate to the legacy app using its native method (Kerberos, NTLM, form-based login, or mutual TLS with injected credentials). The legacy application never receives unauthenticated requests; users never need to know the application's legacy credentials. This enables Zero Trust for brownfield environments without application code changes.

Incorrect·D: A dynamically calculated numerical value based on aggregated telemetry (threat intelligence, device posture, behavior) that dictates whether to allow, block, or step-up authentication

Risk Scoring is the quantitative output of the Trust Algorithm. The Policy Engine aggregates telemetry from multiple sources — threat intelligence feeds (device IP reputation, known malicious domains), EDR device health scores, UEBA behavioral anomaly scores, identity risk signals (credential exposure from HaveIBeenPwned, impossible travel detection), and data sensitivity classifications — and produces a normalized risk score (e.g., 0–100). This score drives dynamic access decisions: low risk → full access; medium risk → allow with MFA step-up; high risk → quarantine the device; critical risk → terminate session and alert SOC. Real-time score updates enable continuous verification throughout a session.

Incorrect·B: IaC enables the automated, error-free, and highly scalable deployment of micro-perimeters and PEPs alongside new cloud workloads

Infrastructure as Code (IaC) — using tools like Terraform, Pulumi, AWS CloudFormation, or Kubernetes manifests — enables Zero Trust policies to be co-deployed automatically alongside cloud workloads. When a new microservice is deployed via a CI/CD pipeline, the IaC config simultaneously deploys the ZTNA connector, configures cloud security group rules, provisions the mTLS certificate via SPIRE, and registers the workload in the IAM system — all in a single automated, reproducible, auditable pipeline. This eliminates manual policy configuration errors, ensures no workload is ever deployed without its ZT micro-perimeter, and scales ZTA to thousands of ephemeral cloud resources without human intervention.

Incorrect·A: APIs are treated as distinct, highly targeted resources requiring mutual authentication (mTLS), strict authorization, and continuous rate-limiting

APIs are primary attack targets in modern architectures — the OWASP API Security Top 10 catalogs the most critical API vulnerabilities. In Zero Trust, APIs are never implicitly trusted regardless of their machine-to-machine nature. Each API endpoint is treated as a protected resource with its own access policy: mutual authentication (mTLS or signed JWTs with short expiry), strict authorization (OAuth 2.0 scopes, ensuring each caller can only invoke the specific operations it needs), continuous rate-limiting (preventing abuse and sudden unusual call volumes that may indicate compromise), input validation (preventing injection attacks), and comprehensive logging of all API calls for behavioral analysis. API gateways (Kong, AWS API Gateway, Apigee) serve as the PEP for API traffic.

Incorrect·C: Dynamic, just-in-time, machine-learning-driven data access based on continuous risk assessment and deep data tagging/classification

The CISA ZTMM Data Pillar progression culminates at the "Optimal" maturity level with fully automated, ML-driven, just-in-time data access based on dynamic risk assessment. At this level: all data is classified and tagged with sensitivity and context metadata (who created it, its regulatory category, lifecycle stage); access is granted dynamically per-request based on real-time risk scoring (user identity, device health, behavioral signals) rather than static role assignments; ML models continuously analyze data access patterns to detect anomalies; data is protected by Information Rights Management (IRM) that travels with the data regardless of location; and DLP enforces policies automatically. The organization effectively protects the data itself, not just the perimeter around it.

Incorrect·D: It allows the ZTA policy engine to automatically and instantly revoke access across the entire network the moment a severe threat is detected by a SIEM

SOAR (Security Orchestration, Automation, and Response) turbocharges Zero Trust's "Continuous Verification" capability by closing the detection-to-response gap. Traditional SOC workflows have human analysts reviewing SIEM alerts, which takes minutes to hours. SOAR automates this: when the SIEM detects a high-confidence compromise indicator (malware alert from EDR, impossible travel, mass data download), a SOAR playbook automatically fires — querying additional context, calculating a confidence score, and if threshold exceeded, calling the ZTA Policy Engine API to immediately revoke all sessions and access tokens for the affected user/device across all applications simultaneously — in seconds, not hours. This automated response dramatically limits breach impact.

Incorrect·B: A system that allows users to use one set of credentials to authenticate and access multiple systems across different trusted, disparate domains (e.g., using SAML or OAuth)

Identity Federation enables Single Sign-On (SSO) across organizational and domain boundaries by establishing trust relationships between Identity Providers (IdPs). Using standards like SAML 2.0, OAuth 2.0, and OIDC, a user can authenticate once to their corporate IdP (e.g., Microsoft Entra ID) and seamlessly access SaaS applications, partner organization systems, and cloud services in other domains without re-authenticating — the IdP issues signed identity assertions (SAML tokens, JWTs) that federated services accept as proof of identity. In Zero Trust, federation is critical for managing access to the diverse cloud ecosystem (M365, Salesforce, AWS, partner extranets) under a single centralized identity policy.

Incorrect·A: It provides the lifecycle management of digital certificates necessary for establishing trust, issuing identities to workloads, and enabling mTLS at scale

PKI is the foundational trust infrastructure of Zero Trust — it provides the digital certificate ecosystem that cryptographic verification relies on. For device identity: PKI issues device certificates that prove a device is corporate-managed. For workload identity: SPIFFE/SPIRE implement PKI to issue short-lived X.509 SVIDs to container workloads. For mTLS: all service-to-service authentication relies on mutual certificate verification. For ZTNA: user and device certificates authenticate to ZTNA gateways. At enterprise scale (thousands of devices, thousands of microservices), PKI lifecycle management — issuance, renewal, revocation (OCSP/CRL), and rotation — must be automated. A compromised or poorly managed CA can undermine the entire Zero Trust architecture.

Incorrect·C: Traditional firewalls must accept and inspect the first packet of any incoming connection, exposing their open ports to network scanning and pre-authentication exploits

The First Packet Problem describes a fundamental architectural vulnerability in traditional firewall-based security: for a firewall to apply rules to incoming traffic, it must first receive and process the packet — meaning the listening port(s) must be open and the server must accept TCP connections before authentication occurs. This exposes the server to reconnaissance (port scanning reveals what services are running), pre-authentication exploits (CVEs that can be triggered before login — like Heartbleed, which attacked TLS before authentication), and denial-of-service attacks (SYN floods against open ports). SDP with SPA eliminates this: the server has no open ports, the first packet is silently dropped unless it is a valid cryptographic SPA authorization — authentication occurs before any connection is possible.

Incorrect·D: It threatens the underlying public-key cryptographic algorithms (like RSA) that ZTA relies on for identity verification and encryption, requiring a transition to Post-Quantum Cryptography

Quantum computers capable of running Shor's Algorithm at sufficient qubit scale will break the RSA and Elliptic Curve Cryptography (ECC) algorithms that underpin virtually all ZTA cryptographic operations: TLS/mTLS certificate authentication, PKI digital signatures, OIDC/SAML token signing, ZTNA session key exchange, and VPN tunneling. The "harvest now, decrypt later" threat is immediate — adversaries are recording encrypted ZTA traffic today for future quantum decryption. NIST finalized Post-Quantum Cryptography (PQC) standards in 2024 (ML-KEM, ML-DSA, SLH-DSA) based on lattice and hash-based mathematics that quantum computers cannot efficiently break. Organizations must begin transitioning ZTA cryptographic primitives to PQC algorithms now — a multi-year effort termed Cryptographic Agility.