#Chapter 5 — Zero Trust Architecture

How to build an access architecture where every request is verified regardless of network location, score yourself honestly against CISA's maturity model, and turn "isolate that host" into a policy change instead of a desk visit.

Who needs this: CISO, security architect, network and identity engineering, IR leads, cloud platform owners | Read time: 22 min | Maps to: CSF 2.0 PROTECT (PR.AA, PR.IR), DETECT (DE.CM), RESPOND (RS.MI); CIS Controls 1, 4, 6, 12, 13; ISO/IEC 27001:2022 A.8.9, A.8.15, A.8.16

Welcome to the chapter everyone has already bought a product for, cyber-friends. Let's talk about what you actually bought.

Colonial Pipeline was compromised through what its CEO described in Senate testimony as a "legacy virtual private network profile that was not intended to be in use," without MFA (Blount testimony). One forgotten account on one forgotten remote-access path, and the network behind it treated the resulting connection as an insider. Equifax is the same story from the inside: GAO records that the company's databases "were not isolated from each other," letting attackers move well beyond the online dispute portal and exfiltrate data "without triggering an alarm," reaching a database holding unencrypted credentials for still more databases (GAO-18-559). Neither is a failure of authentication. Both are failures of what happens after it — the moment a flat network converts one valid session into the run of the estate.

That conversion is faster now. CrowdStrike measured average eCrime breakout time — first foothold to first lateral move — at 29 minutes, fastest observed 27 seconds (CrowdStrike 2026 Global Threat Report). Mandiant puts the median hand-off from initial-access broker to follow-on operator at 22 seconds, down from more than eight hours in 2022 (M-Trends 2026). You will not out-run that with a human on a bridge call. The only thing that keeps up with 22 seconds is architecture that never granted the implicit trust in the first place.

That is what this chapter is about. Not the product. The architecture.

#Zero Trust is an architecture, not a SKU

NIST published SP 800-207, Zero Trust Architecture, as a final document in August 2020, and it remains the conceptual foundation (NIST SP 800-207). Its core assertion is short enough to put on a wall: no implicit trust is granted to assets or accounts based on physical or network location or asset ownership, and protection is oriented around individual resources rather than perimeters. In the document's own words, "authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established."

Read that clause twice, because it is the part vendors skip. Both subject and device. Before a session. Discrete functions. A product that authenticates a user and then hands them a network route has not implemented zero trust; it has implemented a nicer VPN login page.

SP 800-207's logical architecture has three named parts, and naming them in your own environment is more useful than any product evaluation:

The Policy Engine and Policy Administrator together are the Policy Decision Point (PDP). The split matters operationally: a decision made in a place you cannot reach at 03:00 is a decision you cannot change during an incident, and a PEP that keeps honouring a token after the PDP has changed its mind is a control that exists on a slide only.

Draw your own architecture and label every PDP and PEP. Most organizations find the same three things: several PDPs that do not talk to each other, a large population of resources with no PEP at all — anything reachable directly on the LAN — and at least one PEP whose enforcement nobody has ever verified. That is the normal starting position, and it is a better one than a purchase order.

Actionable takeaway: Before you buy anything else, produce a one-page diagram naming every Policy Decision Point and Policy Enforcement Point you operate, and mark in red every resource that has neither. That page is your real baseline, and it costs a whiteboard and an afternoon.

#The CISA maturity model, and scoring yourself in one afternoon

CISA's Zero Trust Maturity Model v2.0, published April 2023, is the scoring instrument to use (CISA ZTMM, ZTMM v2.0 PDF). Free, government-published, and specific enough to argue about — which is what you want in a scoring instrument.

Five pillars:

1. Identity
2. Devices
3. Networks
4. Applications and Workloads
5. Data

Three cross-cutting capabilities, applied across all five pillars: Visibility and Analytics, Automation and Orchestration, Governance.

Four maturity stages:

Two things CISA is explicit about that most summaries drop. Each pillar can progress at its own pace — a mature Identity pillar beside a Traditional Networks pillar is a legitimate state, not a failure. And reaching Optimal requires cross-pillar coordination, so pillar-by-pillar progress eventually stalls without it. Translation for the budget conversation: you can buy five best-of-breed pillar products over three years and still sit at Advanced, because the thing you did not buy is the integration.

If you sell to the defense industrial base, note the parallel instrument. The DoD Zero Trust Strategy (October 2022) uses seven pillars — CISA's five with the two cross-cutting capabilities promoted to full pillars — and sets a Target Level deadline of end of FY2027 (30 September 2027) (DTM 25-003). That date lands on somebody's contract before it lands on yours.

#The afternoon rubric

Score each pillar using the evidence question in the right-hand column. The rule that makes this useful: you may only claim a stage if you can produce the evidence without asking anyone to build a report. If proving it takes a week, you are one stage lower than you think.

Score the three cross-cutting capabilities the same way. They decide whether Advanced ever becomes Optimal.

Actionable takeaway: Book three hours this month with identity, network, endpoint and cloud engineering in one room, score all five pillars and all three cross-cutting capabilities, and write the evidence next to each score. Re-run it every six months and put the scorecards side by side. A maturity model you score once is a poster.

#Every access request verified — what a PDP actually does at 09:00 on a Tuesday

The tenet is easy to say and hard to operationalize: verify every request regardless of network location. A policy decision is a function of signals, and the quality of a zero trust deployment is the quality of the signals its PDP can see. A mid-market organization typically already licenses six: identity and group membership, authentication strength, device compliance from MDM or EDR, identity risk level, named IP location, and its own application tiering. The mistake is treating all six as equally available in an emergency. In Microsoft Entra, Continuous Access Evaluation re-evaluates critical events near real-time and needs no Conditional Access license — it is "available in any tenant" — covering account disable or deletion, password change or reset, MFA enablement, an administrator revoking all refresh tokens, and high user risk. The same document also states that propagation "latency of up to 15 minutes might be observed," that IP locations policy enforcement is instant, that in CAE sessions token lifetime increases to long-lived, up to 28 hours, that CAE does not support guest accounts, and that Conditional Access policy and group-membership changes can take up to one day to reach resource providers — with the documented workaround being explicit session revocation (Continuous access evaluation).

Sit with that for a second: your policy change may take a day to land, but your token may live 28 hours. Those two numbers are the entire reason the containment section of this chapter exists.

The cheap version of a PDP, for an organization with no ZTNA budget: your identity provider is already a policy decision point, and you are probably using about 20% of it. Put every internal web application behind it, add a device-compliance condition on the top five, and require phishing-resistant MFA on privileged roles. Real zero trust progress, zero new spend, two pillars moved.

Two operational rules come straight from Microsoft's own guidance: exclude break-glass and emergency-access accounts from every access policy, including vendor-managed ones, and use report-only mode before you enforce (Conditional Access — block access example, Microsoft-managed policies, Plan your Conditional Access deployment). Break-glass exclusions belong to Chapter 4, but they belong here too: the day you write your first tenant-wide block policy is the day you can lock yourself out of your own PDP, and there is no cable to unplug to fix that.

Actionable takeaway: Pick your five most sensitive internal applications this week and put a device-compliance condition on each — report-only first, then enforced, with a date. Five applications, one condition, existing licences, and a measurable move from Initial to Advanced on two pillars.

#Micro-segmentation, and the visibility purgatory that swallows it

Micro-segmentation decides your blast radius. Equifax is what its absence costs; Volt Typhoon is why nation-state advisories keep naming IT/OT segmentation as a top mitigation, after actors sat in critical infrastructure networks with dwell times of at least five years (CISA AA24-038A).

The sequence is not negotiable, and each step fails differently out of order:

1. Identify crown jewels. Named systems, named business owner, named data. If you segment before you know what matters, you will spend your political capital protecting a print server.
2. Get east-west visibility. Flow logs, host firewall logs, or an agent — you need to know what actually talks to what, because the application documentation is wrong and the people who wrote it have left.
3. Enforce. Deny-by-default around one crown-jewel segment, with a documented allow-list, and a date.

Skip step 1 and you enforce in the wrong place. Skip step 2 and you take production down on a Tuesday afternoon and never get permission to try again. Skip step 3 and you have bought a very expensive network map.

Step 3 is where projects die, and the mechanism deserves naming. Segmentation projects stall at the visibility stage forever, because visibility is comfortable: beautiful dashboards, nothing broken, always one more application to map. Nobody has ever been fired for adding another quarter of discovery. The deny rule is the only step that reduces risk and also the only step that can cause an outage, so it never ships.

The cure is a forcing function written in on day one: each crown-jewel segment gets a fixed observation window, and at the end of it the policy goes into enforcement whether or not the map is complete. Ninety days is generous. When the window closes you enforce with the allow-list you have and break the remaining unknowns in a controlled way with the application team on the call — the fastest documentation-generation technique ever invented.

#A segmentation sequence that finishes

Step 6 is not ceremony. In Kubernetes, a NetworkPolicy object is enforced by the CNI — on EKS it requires the VPC CNI network-policy feature or Calico/Cilium, and a cluster without a policy-enforcing CNI will accept the object and enforce nothing. You will have a green tick in your compliance tool and an open network. Verify from inside the pod. Not from the dashboard.

The cheap version, for organizations with no segmentation product: host firewalls plus cloud-native primitives. Default-deny inbound on workstations with named exceptions removes most workstation-to-workstation lateral movement for the price of a group policy. Security groups, NSGs and NetworkPolicy are already paid for — a database whose security group admits only the application tier's security group is micro-segmentation, and it cost nothing.

Actionable takeaway: Pick one crown-jewel system, open a 90-day observation window with the enforcement date written into the change record on day one, and enforce on that date with the allow-list you have. One segment, finished, beats five segments in permanent discovery.

#ZTNA and the end of the flat VPN

The evidence against network-level remote access is overwhelming, and most of it is not vendor marketing.

Vulnerability exploitation reached 31% of breaches in the 2026 DBIR, overtaking credential abuse (13%) for the first time in that report's 19-year history (SecurityWeek on DBIR 2026). Mandiant records exploits as the top initial infection vector at 32% for the sixth consecutive year, with clusters UNC6201 and UNC5807 specializing in edge and core network devices — VPNs and routers (M-Trends 2026). VulnCheck found 23.43% of KEV-listed vulnerabilities had evidence of exploitation on or before the day the CVE was published, and its new-KEV edge-vendor list for 1H-2026 reads like an inventory of most corporate perimeters: Cisco, Palo Alto, Check Point, F5, Juniper, Fortinet, SonicWall, Ubiquiti, TOTOLINK, Tenda, D-Link, Netgear, Linksys (VulnCheck).

The named campaigns make it concrete. ED 25-03 (25 September 2025) covered Cisco ASA/Firepower CVE-2025-20333 and CVE-2025-20362, which chained give full unauthenticated device control — and Cisco confirmed the actor modified ASA ROM to persist across reboot and upgrade (CISA ED 25-03). Ivanti Connect Secure CVE-2025-0282, Fortinet FortiManager CVE-2024-47575 and Microsoft SharePoint CVE-2025-53770 were jointly responsible for 29 of the NCSC's incidents in its 2024/25 reporting year (NCSC Annual Review 2025). And Salt Typhoon — advisory AA25-239A, agencies in 13 countries — reached 600+ organizations across 80 countries largely through known Cisco vulnerabilities in edge routers, then pivoted through trusted connections into other networks (CISA AA25-239A).

"Pivoted through trusted connections" is the phrase that indicts the flat VPN. A classic VPN authenticates a user and then places a device on the network; everything after that is a routing question. Sophos found that although 97% of ransomware victims had some MFA, coverage was inconsistent across VPNs, firewalls and legacy apps, and 79% of those attacks began with an identity-based approach (Sophos State of Ransomware 2026). The gap is always at the seam.

ZTNA changes the unit of access from network to application: the user authenticates to a broker, the broker evaluates identity and device posture per session, and the connection is stitched to one named application through an outbound-initiated connector — so nothing is listening on the internet and a successful authentication yields one application, not a route.

What that buys, stated without marketing:

Now the honest part, because a chapter that sold ZTNA as a perimeter cure would be the vendor whitepaper this book refuses to be: the broker and its connectors are software too, much of it running on or beside the same appliance families in that KEV list. Replacing a concentrator with a cloud broker changes your exposure profile; it does not delete it. Patch the broker on the clock you would patch a VPN, treat any KEV listing against it as an assume-compromise event with credential rotation, and keep it inside Chapter 10's exposure management and Chapter 14's edge-device playbook.

Start with the highest-value, lowest-friction population: third-party and vendor access. Smallest user group, weakest baseline — only 23% of third-party organizations had fully remediated their MFA issues (Help Net Security on DBIR 2026) — and nobody objects to per-application scoping because they never wanted the full network anyway.

Actionable takeaway: Enumerate every internet-reachable remote-access path you operate — VPN concentrators, RDP gateways, Citrix, jump boxes, vendor portals, that one appliance nobody owns — into a single list with owner, MFA status and last-patched date. Any row with "none" in the MFA column is a Colonial Pipeline row. Fix those first, then move vendor access to per-application brokering.

#Zero Trust as a containment lever

This is the payoff, and most zero trust programs never articulate it to their funders. A mature deployment does not only prevent incidents; it changes what containment is. Isolation stops being a physical act — an engineer walking to a desk, a cable pulled, a switch port shut — and becomes a policy change: central, fast, repeatable, logged.

CISA's federal playbooks list, under both eradication and hardening, "tighten perimeter security (e.g., firewall rulesets, boundary router access control lists) and zero trust access rules" (CISA Federal Government Cybersecurity Incident and Vulnerability Response Playbooks). One line in a federal playbook; here is the operational version.

#The containment lever table

Each of these is a control you have or can build, and each has a documented time-to-effect that belongs in your playbook. Do not write "revoke access" in a runbook. Write which lever, and how long it takes to bite.

Every limit in that table is the vendor's own documented behavior, not a field estimate; the citations are items 12–14 and 17–22 in this chapter's Sources.

#Immediate credential revocation and re-authentication, in the right order

Chapter 4 owns the identity controls and Chapter 14.3 owns the full account-takeover playbook. What belongs here is the architectural sequencing rule, because the wrong order is the most common containment defect I see.

The ordering rule, stated plainly: revoke sessions and reset the credential in the same action, then apply the block policy. Resetting a password before revoking tokens leaves refresh tokens, app-issued sessions and consented OAuth grants alive while alerting the adversary and locking out the legitimate user — a trade in which you give up surprise and gain nothing. Full sequencing, including the non-human identity branch and the OAuth grant removal that a password reset never touches, is in Chapter 14.3.

And the architectural point that makes any of it possible: you can only revoke centrally what was granted centrally. Every application with its own local account, every VPN with its own user database, every appliance with a shared admin password is a place your containment lever does not reach. That is the real return on consolidating access behind a PDP — not elegance, but ending an adversary's access everywhere in one action.

#Measure the lever

Three numbers. Time-to-useless — containment decision to verified inability of the principal to act, where verified means observed (no new tokens, no new sign-ins, no new API calls) rather than assumed. Levers tested this quarter — each row above, with the date it was last fired on a live system and its measured time-to-effect. And for the board, blast radius: the count of identities and network sources that can reach a given crown jewel. That is the number zero trust spend is supposed to move.

Actionable takeaway: Take the containment lever table, fill in your own tools and your own measured time-to-effect for each row, and exercise every lever against a live system at least once a quarter. A containment control you have never fired is a hypothesis. Today. Not after the next incident.

#The roadmap: year one with no new budget, versus what needs money

Two lists. The first has no line item.

#Year one, existing licences and existing people

That moves you from Traditional toward Initial or Advanced on four of five pillars, and every row costs staff time rather than budget. Do it in that order: the crown-jewel list gates everything below it, because without it you will segment and condition the wrong things.

#What genuinely needs investment

Sequence matters here too. Buying the segmentation platform before the crown-jewel list exists leaves you with a license, a consultant and a network map. Buying automation before the containment levers are written and measured automates an unverified procedure at machine speed.

Actionable takeaway: Fund nothing in the second table until the corresponding row in the first is complete. Every purchase should answer a limit you actually hit, and you should be able to state that limit in one sentence.

#Where Zero Trust does not help

Plainly, because a control described as universal is a control nobody can plan around.

It does not stop an unpatched internet-facing appliance from being exploited. KEV remediation is going backwards — only 26% of KEV vulnerabilities were fully remediated by 13,000 polled organizations, down from 38%, with median patching time up to 43 days (Help Net Security on DBIR 2026). Zero trust changes what an attacker reaches after the appliance falls, not whether it falls. Chapter 10.

It does not protect against an authorized user doing authorized things. An insider exfiltrating data they are entitled to read passes every policy check, because every check says yes. Chapters 8 and 9.

It does not make an application safe. A broker will faithfully deliver an authenticated, compliant, low-risk user to a SQL injection vulnerability. Chapters 6 and 14.13.

It does not survive the destruction of your ability to recover. Mandiant's sharpest 2026 finding is the shift to "recovery denial" — operators deliberately targeting backup infrastructure, identity services, virtualization management planes, AD CS certificate templates and hypervisor datastores (M-Trends 2026). Segmentation puts those planes behind their own boundaries; only tested, immutable, out-of-band recovery saves you. Chapter 12.

It does not reach the vendor's copy of your tokens. Third-party involvement appeared in around 48% of breaches, a roughly 60% year-over-year increase (SecurityWeek on DBIR 2026). When a SaaS provider is breached and the attacker replays OAuth tokens you legitimately issued, your policy engine sees a valid grant behaving normally. Chapter 11.

It does not fix legacy OT protocols with no concept of identity. Segmentation and conduit control are the compensating controls, and Volt Typhoon's five-year dwell times say how well they are currently working. Chapter 14.14.

And one that is not technical: it does not survive an organization that will not accept an outage. Enforcement causes breakage. If the answer to every proposed deny rule is "not this quarter," you do not have a zero trust program; you have a zero trust budget.

Actionable takeaway: Write your own version of this list, name the control that owns each gap, and keep it in the same document as your maturity score. A program that cannot state its own limits gets blamed for every incident it was never designed to prevent, and that is how good programs get defunded.

Zero trust is not a place you arrive; it is the removal of one bad assumption — that being inside means being trusted — applied one resource at a time, with a date on each one. Score the pillars, pick a crown jewel, enforce something this quarter, and make sure that when the pager goes off you can end an adversary's access with a policy change rather than a car journey.

Verify everything, segment something, and never trust a network just because it is yours.

#Chapter checklist

• ZT-01A dated Zero Trust target-state document exists, scored against all five CISA ZTMM pillars and all three cross-cutting capabilities, with a current stage, a target stage, a named owner and a target date per pillar. [IG1] [GV.RM] [GV.RR]
• ZT-02A current architecture document names every Policy Decision Point and Policy Enforcement Point in the environment, and explicitly lists resources protected by neither. [IG1] [ID.AM] [CIS 12]
• ZT-03A single list enumerates every internet-reachable remote-access path (VPN, RDP gateway, Citrix, jump host, vendor portal, ZTNA broker) with owner, authentication method and last-patched date, and no entry lists "none" for MFA. [IG1] [PR.AA] [CIS 12]
• ZT-04No remote-access account or profile exists that is not bound to an active directory identity; dormant profiles are disabled within 30 days of last use. [IG1] [PR.AA] [CIS 5]
• ZT-05A crown-jewel register exists listing system, business owner, data classification and dependencies, reviewed at least annually with owner sign-off. [IG1] [ID.AM] [CIS 1]
• ZT-06Break-glass/emergency-access accounts are excluded from every access policy including vendor-managed ones, are alerted on every use, and are tested at least quarterly. [IG1] [PR.AA]
• ZT-07Every new or changed access policy is deployed in report-only (or equivalent audit) mode for a defined period before enforcement, and the report-only evidence is retained with the change record. [IG1] [PR.AA] [A.8.9]
• ZT-08Host-based firewalls are enabled and default-deny inbound on all managed workstations, with a documented, owned and reviewed exception list. [IG1] [PR.IR] [CIS 4]
• ZT-09Every access-policy exclusion group has a named owner and an expiry date, and its membership count is reported at least quarterly. [IG1] [PR.AA] [GV.OV]
• ZT-10Device compliance is an enforced condition of access to at least the top five crown-jewel applications. [IG2] [PR.AA] [CIS 6]
• ZT-11East-west flow logging is enabled for every crown-jewel segment and retained for at least 90 days. [IG2] [DE.CM] [CIS 8] [CIS 13] [A.8.15]
• ZT-12At least one crown-jewel segment is in deny-by-default enforcement — not log-only — with a documented allow-list and a recorded enforcement date, and the next segment has an enforcement date already booked. [IG2] [PR.IR] [CIS 12]
• ZT-13Enforcement of every segmentation policy has been empirically verified by attempting a connection that should be denied, with the test output retained. [IG2] [PR.IR] [CIS 13]
• ZT-14Third-party and vendor access is brokered per application rather than granted at network level, is time-bounded, and is reviewed at least quarterly. [IG2] [PR.AA] [GV.SC] [CIS 15]
• ZT-15The incident response plan contains a containment lever table naming each available lever, its authority, and its measured time-to-effect, including token-lifetime and policy-propagation limits. [IG2] [RS.MI] [CIS 17]
• ZT-16Identity containment is executed as a single atomic action — session revocation plus credential reset — with the block policy applied afterwards, and this order is written into the runbook with the reason. [IG2] [RS.MI] [PR.AA]
• ZT-17A cloud quarantine mechanism that cannot be removed from within the affected account (for example an SCP applied from the management account) is pre-written and has been tested in a non-production account. [IG2] [RS.MI]
• ZT-18Endpoint isolation has been exercised on a live host within the last quarter, and the documented constraints — auto-lift window, offline retry window, VPN and proxy caveats, per-batch device limits — are recorded in the runbook. [IG2] [RS.MI] [CIS 17]
• ZT-19In every Kubernetes cluster, NetworkPolicy enforcement has been verified against a policy-enforcing CNI rather than assumed from the presence of the policy object. [IG2] [PR.IR]
• ZT-20Backup infrastructure, identity/Tier-0 systems and the virtualization management plane are each in their own enforced segment with distinct, non-shared administrative credentials. [IG3] [PR.IR] [CIS 11] [CIS 12]
• ZT-21Identity risk signals and device posture are consumed by the policy engine automatically, and an elevation in risk terminates or forces reauthentication of existing sessions without manual intervention. [IG3] [PR.AA] [DE.CM]
• ZT-22Blast radius for each crown jewel — the count of identities and network sources able to reach it — is measured, trended, and reported to executive leadership at least twice a year. [IG3] [ID.RA] [GV.OV]
• ZT-23A segmentation or containment exercise is run at least annually that measures actual achieved blast radius and actual time-to-useless, with findings tracked to closure. [IG3] [ID.IM] [CIS 18]

#Sources

1. NIST SP 800-207, Zero Trust Architecture — https://csrc.nist.gov/pubs/sp/800/207/final
2. CISA Zero Trust Maturity Model — https://www.cisa.gov/zero-trust-maturity-model
3. CISA Zero Trust Maturity Model v2.0 (PDF) — https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf
4. DTM 25-003, Implementing the DoD Zero Trust Strategy — https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dtm/DTM%2025-003.PDF?ver=i2DzVamcFpNhvo-L7dDeUQ%3D%3D
5. CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks — https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf
6. CISA Emergency Directive ED 25-03 (Cisco ASA/Firepower) — https://www.cisa.gov/news-events/directives/ed-25-03-identify-and-mitigate-potential-compromise-cisco-devices
7. CISA Advisory AA25-239A (Salt Typhoon) — https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a
8. CISA Advisory AA24-038A (Volt Typhoon) — https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a
9. NCSC Annual Review 2025, incident management — https://www.ncsc.gov.uk/collection/ncsc-annual-review-2025/chapter-01-cyber-threat-to-the-uk/incident-management
10. GAO-18-559, Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach — https://www.gao.gov/assets/gao-18-559.pdf
11. Testimony of Joseph Blount, Colonial Pipeline, U.S. Senate Homeland Security and Governmental Affairs Committee — https://www.hsgac.senate.gov/wp-content/uploads/imo/media/doc/Testimony-Blount-2021-06-08.pdf
12. Microsoft, Continuous access evaluation — https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
13. Microsoft, Revoke user access in an emergency in Microsoft Entra ID — https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access
14. Microsoft, Conditional Access: Block access — https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-example
15. Microsoft, Microsoft-managed Conditional Access policies — https://learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies
16. Microsoft, Plan a Conditional Access deployment — https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access
17. Microsoft, Microsoft Graph PowerShell SDK and Microsoft Entra ID Protection — https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-graph-api
18. Microsoft, Take response actions on a device in Microsoft Defender for Endpoint — https://learn.microsoft.com/en-us/defender-endpoint/respond-machine-alerts
19. AWS, Remediating a potentially compromised Amazon EC2 instance — https://docs.aws.amazon.com/guardduty/latest/ug/compromised-ec2.html
20. AWS, Disabling permissions for temporary security credentials — https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html
21. AWS Organizations CLI, attach-policy — https://docs.aws.amazon.com/cli/latest/reference/organizations/attach-policy.html
22. Google Cloud, Mitigate security incidents in GKE — https://docs.cloud.google.com/kubernetes-engine/docs/how-to/security-mitigations
23. VulnCheck, State of Exploitation 1H-2026 — https://www.vulncheck.com/blog/state-of-exploitation-1h-2026
24. Google Cloud / Mandiant, M-Trends 2026 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
25. CrowdStrike 2026 Global Threat Report findings — https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-global-threat-report-findings/
26. SecurityWeek, Verizon DBIR 2026: vulnerability exploitation overtakes credential theft — https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/
27. Help Net Security, Verizon 2026 DBIR findings — https://www.helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/
28. Sophos, State of Ransomware 2026 — https://www.sophos.com/en-us/blog/sophos-state-of-ransomware-2026