Who is accountable for certificate governance when IT and OT security are managed separately?

Why This Matters for Security Teams

When IT and OT security are split, certificate governance becomes a shared-risk problem with no natural owner for failure. The asset owner may control the device, while another team controls the CA, renewal process, or revocation workflow. That split is manageable only if accountability is explicit across issuance, renewal, exception handling, and audit evidence. NIST Cybersecurity Framework 2.0 treats identity and access governance as an ongoing function, not a one-time setup, which is why certificate ownership has to be operational, not just documented.

This is where certificate drift becomes dangerous: expired device certs can halt production, while stale trust chains can silently preserve access long after a change. NHIMG research shows certificate expiry is the leading cause of outages for 45% of organisations, and 59% report greater auditing difficulty because clear ownership and visibility are missing in machine identity programs. That pattern appears in both IT and OT environments, but OT tends to suffer longer remediation cycles because uptime and safety constraints limit fast changes. In practice, many teams discover accountability gaps only after a failed renewal or a production interruption has already occurred, rather than through deliberate control testing.

How It Works in Practice

Practical certificate governance starts by assigning the asset owner, the trust-framework owner, and the operating team distinct responsibilities. In a split IT and OT model, the asset owner typically accepts business accountability, security defines policy, infrastructure or platform teams run issuance and automation, and operations approves maintenance windows and exception handling. That division works only when each step is mapped to a named control owner, a documented renewal threshold, and a clear revocation path.

Good programs treat certificates as lifecycle-managed machine identities, not just technical artifacts. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs frames this as continuous governance across discovery, classification, issuance, rotation, and retirement. That aligns with NIST Cybersecurity Framework 2.0, which expects organisations to maintain identity governance as part of ongoing risk management. In OT, this often means separating policy authority from operational execution so the same team is not approving, issuing, and validating its own exceptions.

• Define who owns each certificate family, by environment and asset class.
• Set renewal SLAs and alert thresholds before expiration becomes urgent.
• Use automated inventory and lifecycle tools to expose orphaned certificates.
• Require documented exception approval for any extended TTL or manual renewal.
• Make revocation and emergency replacement part of incident playbooks.

Where this becomes especially important is in hybrid estates with legacy OT systems, segmented networks, or third-party-managed devices. Those controls tend to break down when certificate renewal depends on manual maintenance windows and multiple teams each believe another group owns the trust chain.

Common Variations and Edge Cases

Tighter certificate governance often increases coordination overhead, requiring organisations to balance resilience against operational friction. That tradeoff is real in OT, where safety certification, vendor support constraints, and downtime windows can make rapid renewal difficult. Best practice is evolving, but there is no universal standard for exact ownership boundaries in split IT and OT models; the right answer depends on whether the certificate secures a business application, a plant asset, a remote access path, or a vendor integration.

One common edge case is the shared CA model, where IT owns the PKI platform but OT owns the endpoint trust decisions. Another is the reverse, where an OT environment uses locally managed certificates but central security still needs audit visibility and revocation authority. NHIMG guidance on NHI Lifecycle Management Guide and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce the same operational point: accountability must be provable, not implied. Where organisations rely on spreadsheets or ad hoc handoffs, the ownership model usually collapses during audits, incident response, or mass renewal events. In those environments, governance fails less because the policy is wrong and more because no team can prove it was responsible at the moment a certificate expired or was revoked.

Related resources from NHI Mgmt Group

• Who is accountable for measurable outcomes in a co-managed MSP security service?
• Who should be accountable for secrets governance when developer productivity and security controls conflict?
• Who is accountable when certificate-based device identity fails in a managed access model?
• Who is accountable for PKI governance when certificate management is centralised across multiple teams?