---
title: "Doctrine 21: Zero Trust Is A Trust Model, Not A Card “Type”"
description: "**Doctrine Claim:** PKI proves who you are. Zero trust constantly questions what you should be allowed to do. It allocates risk explicitly through policy, context, and least privilege. This page is a **Doctrine Guide**. It shows how to apply one…"
url: "https://anthonyveltri.com/guide/doctrine-21-zero-trust-is-a-trust-model-not-a-card-type/"
updated: "2026-02-22"
category: "Architecture & Interfaces"
tags:
  - architecture
  - cybersecurity
  - pki
  - zero trust
---

# Doctrine 21: Zero Trust Is A Trust Model, Not A Card “Type”

**Doctrine Claim:**
PKI proves who you are. Zero trust constantly questions what you should be allowed to do. It allocates risk explicitly through policy, context, and least privilege.

This page is a **Doctrine Guide**. It shows how to apply one principle from the [Doctrine](/doctrine/) in real systems and real constraints. Use it as a reference when you are making decisions, designing workflows, or repairing things that broke under pressure.

---

## Core statement

Zero trust is not a new card, new VPN, or new identity technology.
It is a **trust model** that assumes you are already breached and forces every access decision to earn its way through policy, context, and least privilege.

CAC, PIV, and LinkPass cards are strong identity tokens inside that model.
They are not the model itself.

---

## Why this doctrine exists

Most people in government and big enterprises still think:

- “You have a CAC and you are on the internal network, so you are good.”

That is the old perimeter mindset.

This doctrine exists to:

- Break the “inside = trusted” habit.
- Stop people from confusing **identity tech** (cards, certs, MFA) with a **trust model**.
- Anchor conversations on **authorization, segmentation, and blast radius**, not just login mechanics.

**Framing upgrade:** Zero trust is a **risk allocation model**, not a security product. It does not eliminate risk. It decides where risk lives (Identity owners, Devices, Applications, Data Stewards External Partners, etc), when trust must be re-evaluated, (At login only, continuously, etc), and what should happen when signals degrade (Graceful reduction of access, Forced re authentication, Isolation of the session, etc) . In practice, it forces leaders to make explicit tradeoffs between security, mission tempo, and operational continuity. If “zero trust” becomes random lockouts and operator pain, the problem is usually not the idea of zero trust. The problem is that risk was allocated poorly, or the policy was designed for a perfect world instead of real operations.

## The pattern

[![This diagram illustrates Perimeter Security as a castle and Zero Trust as hotel rooms, outlining core concepts and breach management.](https://anthonyveltri.com/wp-content/uploads/2025/11/zero-trust-vs-perimeter-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/11/zero-trust-vs-perimeter.jpg)
The Security Shift: The Perimeter Model acts like a Castle: once you cross the moat, you are trusted. The Zero Trust Model acts like a Hotel: you need a key card for the front door, the elevator, and your specific room (and the fitness studio, and the pool). Identity replaces location.

### Old model: Castle and moat

Typical CAC/PKI era pattern:

- Strong auth at the edge:
  - CAC / PIV authenticates the user.
- Network perimeter as primary control:
  - VPNs, firewalls, “inside = trusted”.
- Coarse authorization:
  - Big AD groups, large shared drives, “everyone in this org” access.
- Breach is treated as:
  - Edge case.
  - Unlikely scenario.

Effect:

- Once you are in, the system behaves as if you are safe.
- Compromised credentials or an insider can move laterally with little resistance.

---

### Zero trust model: Continuous skepticism

Zero trust flips several defaults:

- **Never trust; always verify**
  - Every request is treated as untrusted.
  - Internal traffic is not magically “trusted” because of location.
- **Identity plus device plus context**
  - Not just “CAC valid”.
  - Also:
    - Device posture.
    - Location and time.
    - Behavioral pattern.
- **Least privilege everywhere**
  - Fine-grained access tied to:
    - Role.
    - Task.
    - Data sensitivity.
    - Current risk level.
- **Assume breach**
  - Design as if:
    - An account is already compromised.
    - A host is already infected.
    - An internal system is already leaking.
- **Contain the blast radius**
  - Micro segmentation.
  - Per application and per dataset controls.
  - Strong logging and detection.

Effect:

- CAC / PKI becomes **one signal** in a richer decision.
- Compromise still hurts, but damage stays bounded.

---

## Comparison: CAC-era use vs zero trust

> “We used to treat the CAC like a master key to the castle.
> If you had it and you were on the right network, you were basically in.
>
>
>
> Zero trust keeps the CAC, but it also puts a lock on every room, checks who you are and what you are carrying at each door, and assumes one of those rooms is already on fire.
> The CAC is still important, it is just no longer the whole story.”

**Old CAC / PKI use**

- CAC proves identity at login.
- Inside the network, many resources are assumed safe to expose.
- Network location is treated as a major trust signal.
- Authorization is broad and role mapping is often fuzzy.
- Breach is a “black swan” to be prevented, not assumed.

**Zero trust use**

- CAC is one strong factor in each access decision.
- Every resource is guarded individually, regardless of network location.
- Network is treated as untrusted transport.
- Authorization is precise, time bound, and regularly reviewed.
- Breach is assumed and architecture is built to contain it.

---

## How to use this doctrine in practice

Use this doctrine to redirect conversations that get stuck at the “card and login” layer.

When you hear:

- “We are zero trust because we use CAC, MFA, and TLS.”

You respond with:

- “Those are important building blocks, but zero trust is the **trust model** they live inside. Show me how access to System X and Dataset Y is re-evaluated **every time**, even from internal networks.”

Concrete moves:

1. **Reframe identity tech as signals**
   - CAC, certs, passwords, FIDO keys, device certs:
     - Treat them as inputs to policy, not as policy itself.
2. **Insist on per-resource policy**
   - For any high value system, ask:
     - “Who can get in?”
     - “Under what conditions?”
     - “What can they see or change once inside?”
     - “What limits lateral movement if this account is compromised?”
3. **Inject “assume breach” into design reviews**
   - When reviewing an architecture:
     - “If this account is hijacked, what can the attacker touch?”
     - “What stops them from pivoting to higher value systems?”
4. **Tie CAC / PKI into the model explicitly**
   - “Yes, we will keep CAC for strong identity.”
   - “But we will stop treating it as a master key to the castle.”

---

## Common failure modes

[![A comparison chart shows “Ready when needed” with checked fire extinguisher versus “Looks ready, is not” with a broken extinguisher box. It highlights the importance of regular checks and documentation for emergency readiness.](https://anthonyveltri.com/wp-content/uploads/2025/12/contingency-vs-theater-04-1024x572.jpg)](https://anthonyveltri.com/wp-content/uploads/2025/12/contingency-vs-theater-04.jpg)
Zero Trust Theater. Buying the tools (Cards/TLS) without changing the policy is Theater (The Binder). True Zero Trust requires the operational reality of verifying every request (The Extinguisher). More background on Real vs. Fake Contingency: If you have a plan but no triggers or rehearsals, you have Theater (The Binder). Real contingency looks like a maintained fire extinguisher. "Bolting on" a plan without integration is Theater. True resilience requires the mechanics (inspections, gauges) to be built into the daily operation.

Use these as red flags during reviews.

- **Card worship**
  - “We issued CACs and enforced TLS, so we are zero trust.”
  - Reality: you hardened the door, you did not change the floor plan.
- **Perimeter nostalgia**
  - Heavy reliance on “inside the VPN” as a trust signal.
  - Little scrutiny of internal east–west traffic.
- **Static entitlements**
  - Roles and groups created once, never cleaned up.
  - People accrete access over careers and nothing is reclaimed.
- **Logging without teeth**
  - “We log everything” but:
    - No one looks.
    - No real-time detection.
    - No playbooks for response.
- **Micro segmentation theater**
  - Lots of VLANs and docs.
  - In reality most key services still reachable broadly.

---

## Doctrine Diagnostic: Review questions (for portfolio or system reviews)

You can treat this as a zero trust doctrine checklist.
For a given system or data set, ask:

If you cannot give a clean answer to these, you are not operating with a real zero-trust model, no matter how many CAC readers you own.

1. **Identity**
   - Is CAC / PKI the only real gate, or one of several signals?
2. **Context**
   - Does access depend on device health, location, and time?
3. **Granularity**
   - Can we easily answer “who can see this specific table, file, or queue”?
4. **Blast radius**
   - If one account is fully compromised, what is the maximum realistic damage?
5. **Monitoring**
   - Will unusual use of that account be detected and acted on quickly?
6. **Lifecycle**
   - How fast are entitlements updated when people change jobs or leave?

### Narrated Video Walkthrough

[Gumlet video player](https://play.gumlet.io/embed/699b68f926981d8913848c7f?background=false&autoplay=false&loop=false&disable_player_controls=false)

Audio narration available for this document | Browse full [library](https://anthonyveltri.com/audio/)

---

### Field notes and examples

- [Session Hijacking in 1999: What A URL Bug Taught Me About Trust Models](https://anthonyveltri.com/session-hijacking-in-1999-what-a-url-bug-taught-me-about-trust-models/)
- [Living With Incomplete Pictures: Notes From High Tempo Systems](https://anthonyveltri.com/living-with-incomplete-pictures-notes-from-high-tempo-systems/)

Last Updated on February 22, 2026

### Related Posts

    [![Abstract graphic with geometric shapes, lines, and dots in neutral and orange tones. A large dark rectangle overlays the left side with the white text: "Stewardship vs. Optimization." The design suggests a theme of technology or systems thinking.](https://anthonyveltri.com/wp-content/uploads/2026/01/doctrine-24-stewardship-vs-optimization.jpg)

#### Doctrine 24: Stewardship Places the Primary Burden on the Steward](https://anthonyveltri.com/guide/doctrine-24-stewardship-places-the-burden-on-the-steward-not-the-parties/)   [![This slide illustrates the relationships among claims, roles, and entitlements in Microsoft 365, as presented in Doctrine 21.](https://anthonyveltri.com/wp-content/uploads/2025/12/doctrine-companion-21-claims.jpg)

#### Doctrine 21 Companion: Claims, Roles, and Entitlements in Microsoft 365](https://anthonyveltri.com/guide/doctrine-21-companion-claims-roles-and-entitlements-in-microsoft-365/)   [![This diagram illustrates increasing salary capacities, with larger houses on higher blocks representing $6k, $24k (median), and $80k per year.](https://anthonyveltri.com/wp-content/uploads/2025/12/field-reports-5-year3.jpg)

#### Field Report: College Financing and the 5-Year Home Runway](https://anthonyveltri.com/guide/field-report-college-financing-and-the-5-year-home-runway/)   [![A graphic with abstract blue and black data and circuit patterns, overlaid with a dark rectangle containing the text "ANNEX L Data Modeling & Vocab Crosswalk.](https://anthonyveltri.com/wp-content/uploads/2025/11/annel-l-data-modeling-and-vocab-crosswalk.jpg)

#### Annex L: The Rosetta Stone for Data Teams: Bridging the Gap Between Technicians and Executives](https://anthonyveltri.com/guide/annex-l-data-modeling-and-vocabulary-crosswalks-in-federated-systems/)   [![A graphic with an abstract, circuit-like pattern in orange and beige tones. A dark box contains the text “ITIL 4 Foundation: A Practitioner Crosswalk.” In the top right, a gray label reads “Doctrine 03 Companion.”.](https://anthonyveltri.com/wp-content/uploads/2026/03/Doctrine-03-Companion-ITIL-4-Foundation-A-Practitioner-Crosswalk.jpg)

#### Doctrine 03 Companion: ITIL 4 Foundation: A Practitioner Crosswalk](https://anthonyveltri.com/guide/doctrine-03-companion-itil-4-foundation-a-practitioner-crosswalk/)   [![Thinking in Probabilities featured title card](https://anthonyveltri.com/wp-content/uploads/2025/11/doctrine-22-thinking-in-probabilities.jpg)

#### Doctrine 22: When "It Depends" Is the Right Answer: How to Think in Probabilities Under Uncertainty](https://anthonyveltri.com/guide/doctrine-22-when-it-depends-is-the-right-answer-how-to-think-in-probabilities-under-uncertainty/)