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 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 #
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.
- Fine-grained access tied to:
- Assume breach
- Design as if:
- An account is already compromised.
- A host is already infected.
- An internal system is already leaking.
- Design as if:
- 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:
- Reframe identity tech as signals
- CAC, certs, passwords, FIDO keys, device certs:
- Treat them as inputs to policy, not as policy itself.
- CAC, certs, passwords, FIDO keys, device certs:
- 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?”
- For any high value system, ask:
- 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?”
- When reviewing an architecture:
- 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 #
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.
- “We log everything” but:
- 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.
- Identity
- Is CAC / PKI the only real gate, or one of several signals?
- Context
- Does access depend on device health, location, and time?
- Granularity
- Can we easily answer “who can see this specific table, file, or queue”?
- Blast radius
- If one account is fully compromised, what is the maximum realistic damage?
- Monitoring
- Will unusual use of that account be detected and acted on quickly?
- Lifecycle
- How fast are entitlements updated when people change jobs or leave?
Last Updated on December 15, 2025
