Zero Trust Cross Cutting Capabilities by Stage

Most zero trust programmes score themselves on the five CISA pillars and then stall, because the three capabilities that join the pillars together, visibility and analytics, automation and orchestration, and governance, were never given an owner. Those three capabilities decide whether a policy decision is informed by fresh signals, whether it is enforced at machine speed, and whether anyone can prove the policy is the right one. This guide goes past the pillar overview and works through each cross-cutting capability stage by stage, pillar by pillar, with the data sources, automation patterns and governance artefacts each stage needs. It is written for zero trust architects, SOC and platform leads, and the assessors who have to score a programme against the CISA Zero Trust Maturity Model (ZTMM) version 2.0.

Key takeaways

The cross-cutting capabilities are scored in every pillar. CISA ZTMM v2.0 expects visibility and analytics, automation and orchestration, and governance inside Identity, Devices, Networks, Applications and Workloads, and Data, so a single SIEM project does not move all five scores.
Visibility feeds the decision, automation enforces it, governance justifies it. In NIST SP 800-207 terms, telemetry and logs feed the policy engine, orchestration drives the policy administrator and enforcement points, and governance defines the rules both follow.
Manual islands survive late into the model. Even at CISA's Advanced stage, privileged user identities are still lifecycle-managed manually and non-compliant devices are isolated by hand, so plan those gaps explicitly.
Automation without governance amplifies mistakes. An automated revocation or quarantine rule needs an owner, a tested rollback and a change record, or it becomes the next outage.
Measure the joins, not the tools. Useful metrics are time from signal to enforcement, share of policies expressed as code, and log source coverage per pillar, not the number of products deployed.

What the three capabilities are and how they differ from the pillars

The CISA Zero Trust Maturity Model Guide covers the pillars and the four stages (Traditional, Initial, Advanced, Optimal). The cross-cutting capabilities sit across those pillars. CISA describes them in section 5.6 of ZTMM v2.0 (April 2023) roughly as follows, paraphrased:

Visibility and Analytics: collecting observable artefacts from enterprise events and analysing them so the results inform policy, support response and build risk profiles before an incident.
Automation and Orchestration: using automated tools and workflows to run security responses across products and services, while keeping oversight of how those automated functions are built and changed.
Governance: defining and enforcing cybersecurity policies, procedures and processes across the pillars to manage risk and meet requirements.

The US Department of Defense goes further and treats two of them as pillars in their own right. The DoD Zero Trust Strategy (October 2022) lists seven pillars, with Automation and Orchestration as pillar six and Visibility and Analytics as pillar seven. The DoD Zero Trust Reference Architecture v2.0 (July 2022) breaks them into capabilities: Policy Engine and Automation (SOAR), Software-Defined Enterprise and Cybersecurity Orchestration for automation, and Analytics and Confidence Scoring, Logging using SIEM, Analytics, and Auditing, Sensors and Telemetry for visibility. See the DoD Zero Trust Strategy and Reference Architecture Guide for the wider DoD model, and Zero Trust Frameworks Compared for how the frameworks line up.

Where they sit in the NIST SP 800-207 architecture

Capability	NIST SP 800-207 component it serves	Concrete inputs or outputs
Visibility and Analytics	Data sources feeding the policy engine (PE)	Continuous diagnostics and mitigation (CDM) device state, threat intelligence feeds, network and system activity logs, SIEM, enterprise PKI and ID management records
Automation and Orchestration	Policy administrator (PA) and policy enforcement points (PEP)	Session set-up and tear-down, token revocation, device quarantine, firewall or microsegment rule changes, ticket creation
Governance	Data access policies and industry compliance system inputs	Access policy definitions, exception registers, risk acceptance, policy change history, audit evidence

NIST SP 800-207 tenet 7 asks the enterprise to collect as much information as possible about the current state of assets, network infrastructure and communications and use it to improve its security posture. That tenet is the visibility capability in one sentence, and it is the one most often met only for the network boundary.

Visibility and Analytics, stage by stage

At Traditional, CISA describes manual, low-fidelity log collection with little analysis. Initial automates collection and analysis for mission-critical functions and checks regularly for gaps. Advanced collects enterprise-wide, including virtual environments, and correlates centrally. Optimal is centralised dynamic monitoring with advanced analysis of logs and events. The pillar rows, paraphrased from ZTMM v2.0:

Pillar	Traditional	Initial	Advanced	Optimal
Identity	Activity logs collected, mainly for privileged accounts; manual analysis	Routine manual analysis plus some automated analysis; limited correlation	Automated analysis across some log types; visibility gaps being closed	Comprehensive awareness through automated analysis including behaviour-based analytics
Devices	Physically labelled inventory; limited software monitoring	Digital identifiers plus manual inventory; some automated anomaly scanning	Automated inventory and endpoint monitoring on standard devices; unauthorised devices detected	Automated status collection for all connected devices, correlated with identities to inform access
Networks	Boundary-focused monitoring	Known-indicator monitoring; telemetry correlated within each environment	Anomaly-based detection; correlation across environments and sources	Enterprise-wide awareness with automated correlation across all detection sources
Applications and Workloads	Some monitoring of mission-critical applications	Profile and security monitoring being automated; better log collection	Automated monitoring for most applications; heuristics to spot trends	Continuous, dynamic monitoring across all applications
Data	Mostly manual visibility into data location and use	Visibility from inventory, categorisation, encryption and access attempts	Enterprise-wide automated analysis and correlation; predictive analytics begins	Full lifecycle visibility with predictive analytics and continuous posture assessment

Practical examples per stage

Initial: forward identity provider sign-in and audit logs, endpoint detection telemetry and cloud control plane logs to one store, and run a monthly gap review against an asset list. For small or Windows-heavy estates, CISA's free Logging Made Easy toolset is a starting point.
Advanced: correlate device compliance state with sign-in events so that a sign-in from a device with no inventory record raises an alert, and add workload and non-human identity logs, not only human users. The SIEM Guide and Cloud Logging and Audit Trail Guide cover the plumbing.
Optimal: analytics outputs a risk or confidence score that the policy engine consumes in near real time, which is what the DoD reference architecture calls analytics and confidence scoring. See SIEM vs UEBA for where behavioural analytics fits.

Retention benchmark: for US federal agencies, OMB M-21-31 (27 August 2021) defines event logging tiers EL0 (not effective) to EL3 (advanced) and sets 12 months in active storage plus 18 months in cold storage for most of its highest-criticality log categories, with full packet capture for 72 hours. It is a useful yardstick even outside government. See the Log Management and Retention Guide.

Automation and Orchestration, stage by stage

CISA describes Traditional as static, manual processes; Initial as automating orchestration and response for critical missions; Advanced as enterprise-wide automated response using context from several sources; and Optimal as responses that adapt dynamically to changing requirements and environments.

Pillar	Traditional	Initial	Advanced	Optimal
Identity	Manual onboarding, offboarding and disabling	Privileged and external identities manual; others automated	Privileged user identities still manual; all others automated across environments	All identities automated across environments based on behaviour and need
Devices	Manual provisioning, configuration and registration	Scripts and tools automate provisioning and deprovisioning	Non-compliant devices identified automatically; isolation manual	Provisioning, monitoring, isolation, remediation and deprovisioning fully automated
Networks	Manual configuration and lifecycle	Some networks automated; resources given defined lifetimes	Automated change management (for example CI/CD) for all networks	Infrastructure as code with automated initiation and expiration
Applications and Workloads	Hosting location and access set manually	Periodic configuration changes for security and performance	Automated configuration changes in response to change	Continuous automated optimisation
Data	Manual or ad hoc policy implementation	Some lifecycle and security policies automated	Mostly automated, tiered implementation	Automated lifecycle and policies for all data as far as possible

Automation patterns that move a stage

Joiner, mover, leaver from the HR source of truth: SCIM provisioning and automatic disablement on termination moves Identity from Traditional to Initial. NIST SP 800-53 AC-2(1) Automated System Account Management is the matching control.
Device compliance to access: mark a device non-compliant in MDM and have conditional access block it automatically. Closing the manual isolation step is what separates Advanced from Optimal in the Devices row.
Signal to revocation: a high-risk identity alert triggers session revocation and a forced re-authentication through the identity provider API, recorded in a SOAR case. This is AC-2 plus IR-4(1) Automated Incident Handling Processes.
Network as code: segmentation and firewall rules in version control, deployed through a pipeline, with expiry dates on temporary rules.
Credential rotation on exposure: when a supplier or tool reports a breach, rotate every credential it held from an inventory, not from memory.

The fifth pattern matters because manual rotation is where programmes fail. In the Cloudflare Thanksgiving breach, one service token and three service accounts exposed in the earlier Okta support breach were not rotated because they were believed to be unused, and an attacker used them weeks later. Automated, inventory-driven rotation with last-used data closes that gap.

Testing and rolling back automation

Run in report-only first: log what a quarantine or revocation playbook would have done for two to four weeks before enforcing.
Pilot rings: enforce for IT staff, then one business unit, then all, with a named owner who can stop the playbook.
Kill switch: every automated enforcement action has a documented manual override and a break-glass account excluded from it, with alerts on its use.
Protect the automation: SOAR and orchestration platforms hold powerful API credentials. See Securing the SOAR platform itself and AI SOC Agents vs SOAR Playbooks.

Governance, stage by stage

CISA's governance descriptions run from ad hoc policies enforced manually or by static mechanisms (Traditional), through defined enterprise policies being implemented with minimal automation (Initial), tiered and tailored policies with automation and multi-source context in access decisions (Advanced), to fully automated enterprise policies with tailored local controls and dynamic updates (Optimal).

Pillar	Initial (paraphrased)	Advanced (paraphrased)	Governance artefact that evidences it
Identity	Enterprise-wide identity policies being defined and implemented, little automation	Enterprise-wide enforcement with automation and periodic updates	Authentication and access policy, access review records, MFA exception register
Devices	Enforced policies for procurement, non-traditional devices, virtual assets and scanning	Enterprise-wide lifecycle policies with accountability and some automated enforcement	Device lifecycle standard, compliance policy baselines in MDM
Networks	Policies tailored to segments, inheriting corporate rules	Automation supports tailored policies and a move away from perimeter protection	Segmentation standard, rule review history, rule expiry records
Applications and Workloads	Enforcement being automated for development, deployment and software asset management	Tiered policies across the application lifecycle, automated where possible	Secure development policy, pipeline policy checks, software inventory
Data	High-level policies with manual, segmented implementation	Enterprise-wide lifecycle enforcement and unified definitions beginning	Data classification scheme, retention schedule, DLP policy set

At Optimal, CISA expects policies to be fully automated and dynamically updated, and for applications that includes dynamic updates through the CI/CD pipeline. In practice that means policy as code: access rules expressed in a policy language, reviewed through pull requests and tested before release. See the Policy-as-Code for Authorisation Guide.

Policy ownership: each enforcement rule has a named business and technical owner, a review date and a link to the risk it treats (CSF 2.0 GV.PO-01).
Exception handling: exclusions from conditional access, MFA or segmentation are recorded with expiry dates. See How to Find Accounts Excluded From MFA and Conditional Access.
Automation change control: playbooks and policy code follow the same change process as production code, with peer review.
Outcome review: governance reviews whether enforcement is reducing risk, not only whether it exists (CSF 2.0 GV.OV-01).

Where identity fits

The Identity pillar rows show the hardest residual gap: at Advanced, CISA still leaves privileged user identities to manual lifecycle management, and the model says little specifically about non-human identities. Service accounts, API keys, OAuth applications and workload identities need the same three capabilities: logs of their use (visibility), automated issuance, rotation and expiry (automation), and an owner and purpose on record (governance). Treat them as a separate workstream rather than assuming human identity automation covers them. See the Zero Trust Identity Guide.

Implementation sequence

Baseline: score each pillar's three cross-cutting rows separately, using evidence, not interviews. Record which stage each pillar reaches for visibility, automation and governance.
Log source coverage first: automation built on partial telemetry acts on partial truth. Bring identity, endpoint, cloud control plane and network logs into one place and define retention.
Write the governance rules before the playbooks: decide who may approve an automated block, what the rollback is and what is out of scope.
Automate the highest-volume manual task in each pillar: usually leaver disablement, device enrolment and firewall rule requests.
Join signals to decisions: feed device compliance and identity risk into access policy, in report-only mode first.
Close the manual islands: privileged identity lifecycle, device isolation and non-human credential rotation.
Re-score quarterly: the Zero Trust Maturity Model Guide gives a level-based assessment method to pair with CISA's stages.

Decision guidance: what to do first by organisation size

Situation	Visibility priority	Automation priority	Governance priority
Small team, mostly SaaS	Identity provider and SaaS audit logs into one place	Built-in identity and MDM automation, not a separate SOAR	Short access policy and exception list
Mid-size hybrid estate	SIEM with endpoint, identity and cloud sources correlated	A handful of high-confidence playbooks (revoke, quarantine)	Policy owners and quarterly review
Large or regulated enterprise	Enterprise-wide correlation including workloads and data	SOAR plus infrastructure and policy as code	Tiered policies, automated evidence, risk-based exceptions

The trade-off is speed against blast radius: the more decisions are automated, the more a wrong signal or a bad rule affects at once. Smaller organisations get more from bundled automation in their identity and device platforms; see Zero Trust for Small Organisations.

Detection and measurement

Log source coverage per pillar: percentage of in-scope systems sending logs to the central store, tracked separately for identity, device, network, application and data sources.
Mean time from signal to enforcement: minutes from a high-risk alert to session revocation or device quarantine.
Automated share of lifecycle events: percentage of joiner, mover and leaver events, including non-human identities, completed without manual tickets.
Policy as code coverage: percentage of access and network rules held in version control with review history.
Exception age: number of policy exceptions past their expiry date.
Playbook false positive rate: automated actions reversed because the trigger was wrong, per month.

Also monitor the automation itself: changes to playbooks, use of break-glass overrides and API calls by the orchestration platform's own credentials.

Common failure patterns

One SIEM, one score: claiming Advanced visibility in every pillar because a SIEM exists, while data and application telemetry never arrive.
Human-only automation: automating employee lifecycle and leaving service accounts and tokens to manual rotation, the gap the Cloudflare breach exposed.
Alerts with no action path: detection fires but nothing is wired to act. In the Uber breach, repeated push prompts were the visible signal of MFA fatigue; alerting and automated response on repeated denied prompts is the control.
Automation without rollback: a quarantine rule with no override locks out a whole site.
Governance on paper: policies exist but enforcement settings drift and nobody compares the two.
Scoring by interview: stage claims not backed by exportable evidence such as coverage reports and change history.

Framework mapping

Capability	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Visibility and Analytics	PR.PS-04, DE.CM-01, DE.CM-03, DE.CM-09, DE.AE-02, ID.AM-01, ID.AM-02	AU-2, AU-6, AU-6(3), AU-12, SI-4, SI-4(2), CA-7, CM-8(3)
Automation and Orchestration	RS.MI-01, PR.PS-01	AC-2(1), AU-6(1), IR-4(1)
Governance	GV.PO-01, GV.OV-01, PR.AA-05	AC-3, PM-31

Practitioner checklist

Score visibility, automation and governance separately in each of the five pillars, with evidence.
List every log source per pillar, its retention and whether it reaches the central store.
Name an owner and review date for every enforcement policy and automated playbook.
Run new playbooks in report-only mode, then pilot rings, with a tested manual override.
Wire device compliance and identity risk signals into access decisions.
Include service accounts, API keys and workload identities in lifecycle automation and rotation.
Move network and access rules into version control with pull request review.
Track signal-to-enforcement time and exception age every month and report them to governance.

Zero Trust Cross Cutting Capabilities: Visibility, Automation and Governance by Maturity Stage