Accountability should sit with the teams that own the assets and the trust framework, but governance must be coordinated across security, infrastructure, and operations. Separate PKIs can reduce cascading failures, yet they still require clear ownership for issuance, renewal, revocation, and exception handling. Without explicit accountability, certificate drift and unresolved trust gaps tend to persist.
Accountability Boundaries in Split IT and OT Certificate Governance
When IT and OT security are managed separately, certificate governance is accountable to the asset owners and the teams that operate the trust infrastructure, not to security in the abstract. That distinction matters because certificates bind identity, access, and device trust across environments that often have different uptime constraints, change windows, and recovery expectations. If ownership is unclear, renewal delays and revocation gaps become operational issues, not just administrative ones.
In practice, teams often discover this only after an expired or misissued certificate interrupts a control path that neither side thought it owned.
How Certificate Governance Actually Works Across IT and OT
Certificate governance spans the full lifecycle: request, issuance, storage, renewal, revocation, replacement, and exception handling. In a split IT and OT model, the governance model should assign operational accountability where the system lives, while central security or infrastructure teams define policy, standards, and oversight. The result is usually a shared model rather than a single owner, because OT environments often need stricter change control and longer maintenance cycles than enterprise IT.
The practical question is not whether certificates are “an IT problem” or an “OT problem.” It is which team can actually act on the certificate at the point of failure. Asset owners must know which certificates exist, where they are installed, how long they remain valid, and what happens if a renewal cannot be completed on time. Security teams should define minimum trust requirements, key handling expectations, and revocation procedures, but they cannot be the only group that understands the operational dependency.
NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, risk ownership, and coordinated control across business functions rather than leaving trust management isolated inside one technical silo. The common failure mode is split responsibility without shared evidence, where each team assumes the other is tracking expiry, replacement, or exception approval. That breaks down fastest in OT, where patching and certificate changes are often delayed by availability constraints.
- Define who approves certificate use for each asset class.
- Track issuance and expiry against the asset inventory, not against a stand-alone PKI list.
- Separate policy ownership from operational execution, but do not separate them from escalation.
- Document which certificates can be renewed automatically and which require manual change control.
Where this model breaks down is when governance exists on paper but no team is empowered to act before trust failures become outages.
Shared Responsibility Gaps, Exceptions, and OT Constraints
Tighter certificate control often increases operational overhead, requiring organisations to balance trust assurance against maintenance windows and legacy-device constraints.
Exception handling is where most split-governance models become fragile. OT assets may not support modern automation, short-lived certificates, or frequent revocation checks, so a policy that works well in IT can create avoidable failure in OT. That does not remove accountability; it changes the control design. The accountable team still needs a process for compensating controls, documented exceptions, and risk acceptance when a certificate cannot be rotated or revoked in the preferred way.
Guidance versus consensus: there is broad agreement that certificate ownership should be explicit, but organisations still vary on whether the central PKI team, the system owner, or the operations function should perform renewal in practice. The safest interpretation is that the team with the closest operational control carries execution responsibility, while the trust and security governance function retains oversight. For hybrid estates, that means shared evidence, named approvers, and a single escalation path for failures that affect both domains.
NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant when organisations need a control-oriented view of accountability, authorisation, monitoring, and system-level enforcement. The practical test is whether the organisation can prove who is responsible for each certificate at every stage of the lifecycle. If it cannot, then governance is fragmented even if the PKI is technically sound.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Split IT and OT certificate ownership is a governance and accountability problem. |
| GV.OV — Oversight | Certificate governance needs cross-function oversight, not isolated team decisions. | |
| ID.AM — Asset Management | Certificate accountability depends on knowing which assets and trust anchors exist. | |
| Recommendation — Assign clear certificate ownership and escalation paths across IT and OT trust domains. Review certificate lifecycle accountability across security, infrastructure, and operations. Map each certificate to its owning asset and update the inventory as systems change. | ||
| CIS Controls v8 | 6 — Access Control Management | Certificates are trust artifacts that govern access and must be owned and tracked. |
| 4 — Secure Configuration of Enterprise Assets and Software | Certificate drift often reflects configuration gaps across managed assets. | |
| Recommendation — Maintain explicit ownership for certificate issuance, renewal, revocation, and exceptions. Inventory certificate-bearing assets and keep trust settings aligned to approved baselines. | ||
Practitioner Guidance
What to prioritise: Assign one named operational owner for each certificate class and one governance owner for the policy. In split IT and OT environments, ambiguity usually appears first at renewal and revocation, so those two actions should have an explicit owner and backup owner.
What to verify: Confirm that the asset inventory, certificate inventory, and exception register agree with one another. If any one of those sources is stale, accountability is already weaker than it appears, because no team can reliably prove what trust material is active where.
Escalation / exception: Treat long-lived exceptions, unsupported OT devices, and manual renewal paths as higher-risk conditions that need periodic review. When a certificate cannot be renewed or revoked through the normal process, the issue is not just technical friction; it is a governance exception that should be time-bound and owned.
Practitioner takeaway: Certificate governance works in split environments only when accountability follows operational control, while oversight remains shared across the teams that define trust, run the assets, and absorb the failure if trust breaks.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- How should security teams use IAST and RASP in NHI governance?
- Why is single-provider AI agent governance not enough for enterprise security?
- What should teams do when cloud security and identity governance are managed separately?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
