Zero Trust Is Not a Product: What the Matrix Reveals

Zero Trust has completed the full marketing cycle. It started as a specific architectural concept (John Kindervag at Forrester, 2010), got adopted by the security industry as a framework (NIST SP 800-207, 2020), and then got turned into a product category by approximately every vendor in the space simultaneously. By 2023, “Zero Trust” appeared in the marketing materials of network vendors, endpoint vendors, identity vendors, data security vendors, and at least a few companies that had renamed existing products without changing them materially.

The result is that “Zero Trust” now means whatever the vendor saying it needs it to mean. That’s a problem for buyers trying to make architectural decisions rather than procurement decisions.

The CDM cuts through this cleanly. Zero Trust, properly understood, maps to two specific columns in the matrix. Understanding that mapping tells you what a Zero Trust architecture actually requires across each asset class, where the coverage gaps typically are, and why most “Zero Trust” implementations fall short of the concept.

What Zero Trust actually says

The core principle, stripped of marketing: don’t grant access based on network location. Treat every access request as potentially coming from an untrusted context, regardless of whether the request originates inside or outside your perimeter. Verify the trustworthiness of the requestor before granting access, every time.

NIST SP 800-207 defines three core Zero Trust tenets that are relevant here:

All resources are accessed securely regardless of location. The network location of a device (inside the corporate LAN, on a VPN, in a cloud environment) does not determine its trustworthiness.

Access to resources is granted on a least-privilege basis and is strictly enforced. Access decisions are dynamic and based on the current assessed state of the requestor, not on a static role or group membership.

All traffic is inspected and logged. You can’t enforce what you can’t see.

Those principles describe two distinct security activities: establishing trustworthiness (an Identify function) and enforcing access policy based on that trustworthiness (a Protect function). Zero Trust is fundamentally an Identify-to-Protect architecture.

The CDM mapping

Yu’s “Reloaded” presentation maps Zero Trust directly to the Identify and Protect columns across all five asset rows. The mapping looks like this:

Devices/Identify: Device certificates, device health attestation, hardware security modules, endpoint posture assessment. The question: is this device what it claims to be, and is it in a state we consider trustworthy?

Devices/Protect: Host-based firewalls, endpoint detection and response in prevention mode, application allowlisting, micro-segmentation at the endpoint level. The question: given what we know about this device’s trustworthiness, what is it allowed to do?

Applications/Identify: SSL/TLS certificates for application identity, API authentication tokens, software attestation. The question: is this application or API endpoint what it claims to be?

Applications/Protect: API gateways enforcing authorization policy, mutual TLS between services, runtime application self-protection. The question: given the established identity of the calling application, what operations is it allowed to perform?

Networks/Identify: IP address (weak, but still used), Software-Defined Perimeter / Single Packet Authorization, network device certificates. The question: what do we know about the trustworthiness of the network path this traffic is using?

Networks/Protect: Zero Trust Network Access (ZTNA) replacing VPN, microsegmentation, default-deny network policies, encrypted tunnels for all traffic. The question: given the assessed network context, what connectivity is allowed?

Data/Identify: Data classification, data integrity verification (hashes and checksums), data lineage tracking. The question: what is this data, how sensitive is it, and has it been tampered with?

Data/Protect: Encryption at rest and in transit, tokenization, rights management, attribute-based access control tied to data classification. The question: given who is requesting access to this data and their current trustworthiness assessment, are they authorized?

Users/Identify: Passwords (weak), hardware tokens, FIDO2/passkeys, biometrics, behavioral analytics establishing a baseline for what “this user acting normally” looks like. The question: is this person who they claim to be, and are they behaving consistently with their established pattern?

Users/Protect: Multi-factor authentication enforcement, step-up authentication for sensitive operations, privileged access management, session monitoring. The question: given the established identity and context, what is this user authorized to do in this session?

Where most Zero Trust implementations fall short

The mapping reveals the gap immediately. Most implementations that call themselves Zero Trust have strong coverage in Users/Identify (MFA is well understood and widely deployed) and moderate coverage in Networks/Protect (ZTNA replacing VPN is a well-defined product category). Everything else is thin.

Devices/Identify is weak in most environments. Device certificate infrastructure is complex to maintain at scale. Device health attestation (is this device patched, is the endpoint agent running, is disk encryption enabled?) requires integration between your MDM, your identity provider, and your access control policy engine. Most organizations have parts of this but not the full chain: they can verify user identity strongly but can’t dynamically adjust access based on the current health state of the device the user is on.

Applications/Identify is largely absent in legacy environments. Mutual TLS between services is standard in cloud-native architectures built in the last five years. It’s rare in legacy enterprise environments with application portfolios that predate the Zero Trust era. An application that authenticates users strongly but doesn’t authenticate to the services it calls is a Zero Trust gap.

Data/Identify is underdeveloped almost everywhere. Data classification at the level of granularity required for attribute-based access control is hard. It requires knowing what data you have (Data/Identify in the CDM base model, before the Zero Trust layer), classifying it accurately, and maintaining that classification as data moves and evolves. Most organizations have a data classification policy. Fewer have implemented it at the technical level where access control decisions can be made against it in real time.

Networks/Identify is philosophically awkward. The original Zero Trust insight was that network location is not a trustworthiness signal. If you’re building a Zero Trust architecture, you’re explicitly de-emphasizing network identity. But you still need to verify something about the network context: is this traffic coming from a known endpoint, via an authenticated tunnel, or from an anonymous internet connection? Single Packet Authorization and ZTNA tools address this, but the conceptual tension between “the network doesn’t determine trust” and “we still need to evaluate network context” is real.

Zero Trust as a CDM completeness check

The practical value of this mapping for security architects: use the Zero Trust columns (Identify and Protect) as a completeness check against your architecture.

For each row, ask two questions: what signals am I using to establish trustworthiness of assets in this class, and how am I enforcing access policy based on that trustworthiness assessment?

If the answer to either question for any row is “we’re not doing that systematically,” you have a Zero Trust gap in that row. The gap might be acceptable given your risk profile and the threat model for that asset class. But it should be a known gap, not an unknown one.

This exercise also reveals where Zero Trust product marketing doesn’t match architectural reality. A vendor selling “Zero Trust for the network” is selling you Networks/Protect capability. It doesn’t close the gaps in Devices/Identify, Users/Identify, or Data/Protect. Buying a ZTNA product and calling your architecture Zero Trust is like covering two cells in a row and calling the row protected.

The Detect and Respond gap in Zero Trust architectures

One thing the CDM mapping of Zero Trust makes visible that the standard Zero Trust literature often underemphasizes: Zero Trust is an Identify and Protect architecture. It has almost nothing to say about Detect, Respond, and Recover.

This is significant. A well-implemented Zero Trust architecture reduces the blast radius of a credential compromise (the attacker can’t move laterally because network access is per-session and per-resource rather than broad) and reduces the risk of network-based lateral movement. But if an attacker compromises a legitimate user credential and device, they can operate within the bounds of that user’s authorized access without triggering the Zero Trust controls. The access looks legitimate because it is, from the architecture’s perspective.

Detection of that scenario requires behavioral analytics (Users/Detect), application-layer logging (Applications/Detect), and data access monitoring (Data/Detect). None of those are Zero Trust components. They’re the Detect column capability that needs to exist alongside the Zero Trust Identify and Protect architecture.

The CDM makes this visible immediately: a mature Zero Trust implementation fills in the Identify and Protect columns well. The Detect, Respond, and Recover columns are a separate investment. Organizations that assume Zero Trust replaces the need for a detection and response program are misreading the architecture.

The Japan-specific Zero Trust context

METI (Ministry of Economy, Trade and Industry) published a Zero Trust architecture reference document in 2022 (ゼロトラスト移行のすゝめ) that has driven significant interest in Zero Trust concepts in Japanese enterprise security. The document is thoughtful and aligns reasonably well with NIST SP 800-207.

What the METI document doesn’t resolve, and where the CDM mapping helps, is the asset-class specificity problem. Japanese enterprise environments often have significant legacy application portfolios, extensive on-premises infrastructure, and complex IT/OT boundaries in manufacturing and utility sectors. The Zero Trust implementations that make sense for a cloud-native financial services firm in Singapore look different from what’s achievable in a mixed IT/OT environment at a Japanese manufacturer.

The CDM row-by-row analysis forces that specificity. Zero Trust for the Users row (strong authentication, behavioral analytics) is achievable in almost any environment and should be the first priority. Zero Trust for the Applications row in a legacy environment requires application modernization investment that may have a longer timeline than the security program controls. Zero Trust for the Networks row in an OT environment requires careful scoping because default-deny network policy in an operational technology context carries different risk than in an IT context.

Starting with what’s achievable, being honest about what isn’t, and documenting the gaps is more useful than claiming a Zero Trust architecture when coverage is actually partial.

Next: Article 10 — Mapping CDM to Kill Chain, ATT&CK, and CIS Controls