Accountability sits with the owners of the systems that share trust, not just the team that first detects the intrusion. When a breach spreads across connected systems, security, network, identity, and mission owners all share responsibility for the trust paths that made movement possible. Governance should define who can revoke links, who can isolate enclaves, and who owns recovery decisions.
Why This Matters for Security Teams
When a defence network compromise spreads across connected systems, the core issue is not just intrusion detection. It is shared trust. If identity links, service accounts, API keys, routing paths, or enclave trust relationships are left intact, one compromised foothold can move laterally across mission systems faster than teams can coordinate a response. That makes accountability a governance problem as much as a technical one.
Current guidance from NIST SP 800-207 Zero Trust Architecture is clear that trust should be continuously evaluated, not assumed from network location. NHIMG research shows why this matters operationally: in the Ultimate Guide to NHIs, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That is a reminder that connected defence environments often fail through identity sprawl, not only perimeter failure.
In practice, many security teams discover shared accountability only after one enclave has already trusted another for far too long.
How It Works in Practice
Accountability needs to follow the trust path, not the alert source. The team that detects the compromise may lead triage, but the owners of identity, network segmentation, platform, and mission services must each own the controls that allowed propagation. That includes revoking credentials, isolating segments, disabling trust bridges, and deciding which systems can safely remain online during recovery.
For connected defence networks, the practical model is to predefine decision rights before an incident. That usually means:
- System owners define which links between enclaves are allowed and which are revocable on demand.
- Identity teams own service account and secret revocation, including API keys and machine credentials.
- Network teams own isolation actions such as ACL changes, route cuts, and segment quarantine.
- Mission owners decide what operational loss is acceptable during containment and restoration.
This is where NIST SP 800-53 Rev 5 Security and Privacy Controls becomes useful in practice, because it gives teams a way to map containment, access control, and recovery responsibilities to named control families rather than informal handoffs. NHIMG’s 52 NHI Breaches Analysis reinforces the same pattern: compromise spreads when machine identity governance is weak, stale, or unclear.
Where organisations get this wrong is assuming that incident response alone can compensate for shared trust that was never formally owned.
Common Variations and Edge Cases
Tighter containment often increases operational disruption, so organisations must balance mission continuity against the speed of isolation. That tradeoff is especially hard in defence environments where availability matters, but there is no universal standard for this yet on how much autonomy each owner should have during cross-domain compromise.
Some environments require a central incident commander with the authority to cut trust paths immediately. Others use distributed ownership, where enclave, identity, and mission leads can act within pre-approved limits. Best practice is evolving toward the second model only when the limits are explicit, tested, and auditable. If they are not, response becomes slow and political, and the attacker benefits from delay.
One important edge case is third-party connectivity. If a compromise spreads through suppliers, managed platforms, or remote support channels, accountability still remains with the internal owners who approved and monitored those trust relationships. Another edge case is partial visibility: if teams cannot see service-account use or secret sprawl, they cannot confidently assign containment actions. In those cases, accountability must include remediation of the visibility gap itself, not just the compromised hosts.
In connected defence networks, the hardest failures happen when everyone is responsible in theory, but no one is authorised to sever the path in time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.CO-2 | Cross-team response coordination is central when compromise spreads across systems. |
| NIST Zero Trust (SP 800-207) | SC-7 | Segmentation and controlled trust paths determine whether compromise can move laterally. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Service accounts and API keys are common spread mechanisms in connected environments. |
| CSA MAESTRO | M1 | Shared ownership of autonomous and connected systems needs explicit governance and response boundaries. |
| NIST AI RMF | Governance of system impact and accountability supports safe response across automated environments. |
Assign incident coordination roles and decision rights before an event so containment actions are not delayed.
Related resources from NHI Mgmt Group
- Who is accountable when AI-driven compromise spreads through OT systems?
- Who is accountable when network hardware is later found to pose supply chain risk?
- Who is accountable when a third-party script causes downstream compromise?
- Why do support systems create identity and trust risk even without account compromise?
