Who is accountable for maintaining trusted machine identities across defence and command infrastructure?

Why This Matters for Security Teams

Trusted machine identities are not a narrow certificate issue. In defence and command environments, they are the control plane for service authentication, workload trust, automation safety, and recovery under pressure. When accountability is unclear, issuance drifts, renewal breaks, revocation is delayed, and incident response loses the ability to distinguish legitimate automation from compromise. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats identity, access, and system integrity as shared governance concerns, which is the right starting point for operational ownership.

NHIMG research shows how quickly identity failures become exposure: in the 2026 Infrastructure Identity Survey, 67% of organisations still relied heavily on static credentials, while 70% granted AI systems more access than they would give a human in the same role. In contested environments, that pattern creates a direct path from one weak identity to a wider operational breach.

In practice, many security teams discover identity ownership gaps only after certificates fail during an exercise or a privileged workload is abused in production, rather than through intentional governance.

How It Works in Practice

Accountability should be assigned by control domain, not by convenience. The system owner is accountable for the workload’s identity lifecycle needs, security is accountable for policy and assurance, and operations is accountable for execution during normal and degraded states. For machine identities, that means clearly named owners for issuance, renewal, revocation, logging, exception handling, and recovery. Without that split, no one owns the full chain of trust.

Practically, mature programmes use workload identity as the primitive, not shared secrets. That means short-lived certificates or tokens, automated rotation, and policy checks at request time. Guidance from SPIFFE is relevant here because it frames identity as a cryptographic proof of workload identity, while NIST SP 800-53 Rev 5 supports the surrounding governance controls for access, audit, and integrity.

For defence and command infrastructure, this usually means:

• Defining a named owner for every machine identity and service principal.
• Using automated issuance and renewal tied to workload posture, not manual ticketing.
• Revoking credentials immediately when a system is retired, reimaged, or isolated.
• Monitoring certificate and token use for unusual east-west movement or privilege escalation.
• Testing recovery paths so trusted identity still works during outages, segmentation events, or degraded command links.

NHIMG analysis of real-world identity abuse illustrates why this matters. The JetBrains GitHub plugin token exposure case shows how quickly exposed credentials can become a broader trust failure once automation and developer tooling are in the same blast radius. These controls tend to break down when legacy platforms require shared service accounts because ownership, rotation, and revocation cannot be tied cleanly to a single workload.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance assurance against continuity, especially in mission systems that cannot tolerate frequent manual intervention. That tradeoff is real in defence networks, where classified enclaves, air gaps, intermittent links, and legacy middleware can make modern automation difficult.

Current guidance suggests that there is no universal standard for who must “own” machine identity in every environment. In practice, the accountable party is usually the system owner, but the control implementation may sit with platform engineering, PKI teams, or cyber operations depending on the architecture. What matters is that one party is explicitly accountable for lifecycle outcomes, not merely technical administration.

Edge cases include shared command platforms, coalition interoperability, and systems with embedded devices that cannot support rapid rotation. In those cases, compensating controls become essential: shorter certificate lifetimes where feasible, segment-specific trust anchors, strict audit logging, and emergency revocation procedures tested in exercises. NHIMG’s DeepSeek breach coverage reinforces the wider lesson that exposed secrets and weak identity hygiene turn quickly into trust collapse. Best practice is evolving, but the accountability model should remain simple: one owner for the workload, one owner for the policy, and one tested process for recovery.

Related resources from NHI Mgmt Group

• Who is accountable for maintaining least privilege across human and machine identities in cloud platforms?
• How should security teams evaluate privileged access management before deploying it across human, machine, and certificate identities?
• Who is accountable when machine-to-machine authentication is not continuously verified in critical infrastructure?
• Who is accountable when machine identities are introduced into an ATO boundary?