They should be able to answer where every certificate is issued, what device or service uses it, when it expires, and how quickly it can be revoked. If that inventory is incomplete, trust is being managed blindly rather than governed.
When OT certificate governance is actually working
Security teams should look for evidence that the certificate estate is visible, mapped to real OT assets, and governed through change rather than assumption. In practice, that means the team can identify each certificate, its issuing authority, its intended device or service, and its expiry path without relying on tribal knowledge or ad hoc discovery.
A working governance model also means certificate decisions are operational, not theoretical. Renewal, revocation, and replacement should be predictable enough that an expired or compromised certificate becomes an exception that is detected and handled quickly, rather than a surprise found after service disruption or trust failure.
What a usable OT certificate inventory proves
The inventory is the control surface. If it cannot show where certificates are issued, where they are deployed, and what they authenticate, then the organisation does not really know what trust depends on. That matters in OT because certificate sprawl often hides in HMIs, historians, remote access gateways, engineering stations, and service-to-service paths that are not managed like ordinary IT endpoints.
For Machine Identity, PKI and Certificate Lifecycle Guide, the practical test is whether the team can connect certificate records to lifecycle state, not just count how many certificates exist. If issuance data, subject usage, expiry, and revocation status are separate views, governance is still fragmented even if each view looks complete on its own.
In OT environments, this also means understanding the trust dependency. A certificate may protect device authentication, encrypted transport, remote administration, or vendor access, and each of those use cases creates a different operational consequence if the certificate lapses or is revoked too late.
How teams know the control is not just a spreadsheet
Governance is working only when the inventory drives action. That includes a clear owner for each certificate, a documented renewal window, a tested revocation process, and a way to confirm that expired material cannot continue to authenticate devices or operators unnoticed.
For operational technology, OT and ICS Identity and Access Guide is relevant because certificate governance has to fit the realities of shared assets, vendor support, and segmented environments. If a certificate change can break production access, teams need proof that maintenance windows, fallback paths, and recovery steps are defined before the change is needed.
One good indicator is whether the team can answer the revocation question under pressure: if a certificate must be withdrawn today, how fast can that change be propagated to the OT device, service, or gateway that trusts it? If the answer depends on manual coordination across multiple teams, the governance model is too slow for the blast radius it is supposed to control.
Why expiry, revocation, and trust mapping matter
Certificate governance fails in predictable ways when expiry is treated as a calendar event rather than an operational dependency. OT systems often stay in service for long periods, so certificates can outlive the people who installed them and the records that explain why they exist.
The strongest external benchmark is the public certificate lifecycle model, including CA/Browser Forum expectations around issuance and revocation, because it reinforces that trust is not static. CA/Browser Forum is useful here as a baseline for disciplined issuance and revocation behavior, even when the OT environment itself is privately managed.
When an organisation can only say “we think the certificate is still in use,” that is a sign the trust model is incomplete. Good governance should expose the opposite: which device or service depends on the certificate, what happens if it expires, and what evidence proves it was removed from use when revoked.
Risk and Threat Considerations
OT certificate governance breaks down when unknown or long-lived certificates keep authenticating critical services after the team has lost track of them. That creates hidden trust paths, delayed revocation, and a larger compromise window if an attacker steals a private key or abuses an unmanaged certificate.
Failure mechanism: Certificates remain valid past their intended use because inventory, ownership, and revocation are incomplete, so trust survives after control has been lost.
Impact: Attackers or insiders can keep authenticating to OT systems, service interruptions can occur during forced expiry, and teams may not notice until a device, gateway, or vendor path stops behaving as expected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OT certificate governance depends on lifecycle control of authenticators and revocation. |
| IA-9 — Service Identification and Authentication | OT certificates often authenticate devices and services rather than people. | |
| AC-3 — Access Enforcement | Certificates govern which OT services and devices are trusted to connect. | |
| Recommendation — Manage certificate issuance, expiry, rotation, and revocation as controlled authenticators. Bind certificates to device and service identities with controlled trust anchors. Enforce access decisions so only approved certificate-backed connections are accepted. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Certificate governance is an access-control issue because certificates grant trust. |
| A.5.16 — Identity management | Certificate inventories must map each certificate to the device or service it represents. | |
| Recommendation — Define and enforce certificate-based access rules across OT assets. Maintain authoritative identity records for certificate-bearing OT assets. | ||
Practitioner Guidance
What to verify: Require evidence that every certificate is linked to an owner, an asset or service, an issuing authority, an expiry date, and a revocation path. If any one of those fields is missing for a production OT certificate, treat the control as partially blind rather than functioning.
What good looks like: The team can show a current inventory, prove which certificates are still active, and demonstrate that renewal and revocation are tested in a way that matches OT maintenance constraints. A mature program does not depend on memory, email threads, or one person who “knows the environment.”
Decision rule: If a certificate supports authentication to an OT device or remote path, prioritise ownership, expiry handling, and revocation testing before expanding the inventory with low-value details. The point is to reduce ungoverned trust first.
Practitioner takeaway: OT certificate governance is working when trust can be traced and changed faster than it can surprise you, not when the certificate count simply looks organized.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org