Who is accountable when zero trust coverage is only partial?

Why This Matters for Security Teams

Partial zero trust coverage creates a false sense of consistency: some access paths are evaluated continuously, while others still rely on legacy trust, static network position, or exceptions that no one can fully explain later. That is why accountability matters. When the programme cannot prove policy enforcement end to end, the issue is not just technical coverage, it is ownership of the decision path itself. NIST’s NIST SP 800-207 Zero Trust Architecture treats policy enforcement as an architectural discipline, not a checkbox.

For NHI-heavy environments, the problem is more visible because service accounts, API keys, and workload tokens often sit outside the same governance loop as users and devices. NHIMG’s Ultimate Guide to NHIs shows how common this gap is, especially where secrets live in code, CI/CD, and other exposed paths. The practical question is who owns remediation when policy coverage is uneven, because “shared responsibility” often becomes no responsibility at all. In practice, many security teams encounter privilege drift and policy exceptions only after an audit failure or credential exposure has already made the coverage gap impossible to ignore.

How It Works in Practice

Accountability usually follows the team that owns the access decision path, meaning the group that can enforce, monitor, and change the policy that allowed the access in the first place. If zero trust is partial, that ownership must include the gaps, not just the covered systems. Current guidance suggests aligning governance to the full request chain: identity proofing, device posture, workload identity, policy evaluation, and privileged access review.

In practice, that means security teams need to answer three questions for every uncovered path: who can grant access, who can revoke it, and who can prove the control is operating as designed. That is where a link between architecture and operating model becomes essential. The Guide to SPIFFE and SPIRE is useful because workload identity gives teams a cryptographic way to distinguish what the workload is, rather than relying only on network location or static secrets. For human and device flows, NIST SP 800-63 Digital Identity Guidelines helps anchor identity assurance, while Ultimate Guide to NHIs -- Standards is a better fit for understanding how NHI controls should be mapped to governance and lifecycle expectations.

• If the policy engine is owned by platform engineering, that team owns policy enforcement quality.
• If privileged access exceptions are approved by security, security owns the risk acceptance record.
• If application teams embed long-lived secrets, those teams own the remediation path for replacing them.

Operationally, the cleanest model is shared execution with a single accountable owner for each access path, supported by evidence from logs, policy-as-code, and exception registers. These controls tend to break down when workloads span multiple clouds and legacy systems because identity, policy, and telemetry are split across teams that cannot see the same request in real time.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance clear ownership against the reality of hybrid estates and inherited platforms. In some environments, the accountable party is not the infrastructure team but the product or application owner, especially when access is embedded in code or automated pipelines.

There is no universal standard for this yet, but current guidance suggests using the principle of control ownership: the team that can change the policy, rotate the credential, or close the exception should be accountable for the risk. That becomes especially important where NHIs are involved, because static secrets and service accounts often bypass the user-centric workflows that traditional IAM teams monitor. The scale of that problem is clear in NHIMG’s research, where NHIs are shown to be far harder to govern than many organisations expect, and the gap between policy design and operational enforcement is often the real failure point.

Edge cases usually appear when third parties, shared platforms, or emergency break-glass access are involved. In those scenarios, accountability should be explicit in change records and exception reviews, because “temporary” controls tend to persist long after the original justification has expired.

Related resources from NHI Mgmt Group

• How should organisations use a Zero Trust gap analysis in practice?
• When do IAST and RASP create a false sense of coverage for NHIs?
• Why does cloud identity coverage matter in federal Zero Trust programmes?
• Who is accountable for cryptographic posture management in a zero trust programme?