A separate PKI is a distinct public key infrastructure used for a specific environment, such as OT or IT. Splitting trust domains can reduce cascading failures, simplify governance boundaries, and limit the impact of certificate issues. It still requires disciplined enrollment, renewal, revocation, and policy management.
Expanded Definition
Separate PKI means operating a distinct public key infrastructure for a defined trust domain, such as OT, corporate IT, partner access, or machine-to-machine workloads. In NHI security, the point is not simply to issue different certificates, but to isolate policy, enrollment, renewal, revocation, and root trust so that one environment does not automatically inherit another environment’s failure mode. That distinction matters because certificate lifecycle mistakes often spread faster than teams expect, especially when automation depends on shared trust anchors.
Definitions vary across vendors on how far separation should go. Some organisations use separate intermediates under one root, while others require fully independent roots, separate HSMs, and segregated administration. The operational choice depends on risk tolerance, regulatory boundaries, and blast-radius goals, but the governance principle is consistent: each trust domain should be able to fail without collapsing every dependent NHI. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, risk management, and resilient identity operations across domains.
The most common misapplication is treating a separate PKI as a branding exercise, which occurs when teams issue different certificate labels but still share the same keys, approval paths, and revocation processes.
Examples and Use Cases
Implementing separate PKI rigorously often introduces operational overhead, requiring organisations to weigh stronger containment against duplicated administration, monitoring, and renewal workflows.
- An OT plant uses one PKI for industrial controllers and another for corporate laptops so a compromise in office IT does not automatically trust shop-floor devices.
- A cloud platform maintains a dedicated PKI for workload identities and service accounts, while user access remains on a different enterprise PKI with different policy and revocation controls.
- A regulated subsidiary runs its own issuance hierarchy to keep certificate governance aligned with local compliance requirements and audit scope.
- A partner integration program uses a narrow trust domain for external APIs, reducing exposure if a third-party certificate lifecycle process is delayed or mismanaged.
This separation is often discussed alongside broader NHI governance in the Ultimate Guide to NHIs, especially when certificate-backed service identities are part of a larger automation estate. It also aligns with guidance in NIST Cybersecurity Framework 2.0 on limiting the spread of security failures across business functions.
Why It Matters in NHI Security
Separate PKI is a resilience control as much as an identity control. When certificates power agents, workloads, APIs, or device-to-device trust, a single bad issuance policy, misconfigured revocation path, or expired root can interrupt authentication at scale. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and 71% of NHIs are not rotated within recommended time frames, both of which make certificate governance harder when trust domains are blended. The problem is not just compromise; it is operational collapse when one certificate mistake becomes a shared outage.
A properly separated PKI also helps security teams apply different rules for OT, IT, and partner ecosystems without forcing one policy onto all of them. That matters because certificate renewal windows, cryptographic requirements, and revocation expectations are rarely identical across environments. It also supports cleaner incident containment when an issuing CA or enrollment workflow is suspected of abuse. The broader identity risk picture described in the Ultimate Guide to NHIs shows why lifecycle discipline cannot be separated from trust design.
Organisations typically encounter the business impact only after expired certificates, broken automation, or a trust-store compromise forces emergency recovery, at which point separate PKI becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Separate trust domains reduce certificate blast radius and contain NHI failure impact. |
| NIST Zero Trust (SP 800-207) | §2.1 | Zero Trust expects isolated trust decisions rather than implicit shared confidence. |
| NIST CSF 2.0 | PR.AA | Identity and access assurance depends on strong issuance, validation, and lifecycle controls. |
| NIST SP 800-63 | AAL2 | Assurance guidance informs how certificate-backed identities should be issued and trusted. |
| CSA MAESTRO | IDM-03 | Agentic and workload identities need segregated trust and lifecycle controls. |
Segment certificate authorities and policies so one domain's compromise does not invalidate all NHIs.
Related resources from NHI Mgmt Group
- Should organisations manage FIDO2 and PKI in separate programmes?
- What breaks when organisations manage PKI certificates and FIDO2 passkeys in separate workflows?
- Should organisations build separate controls for AI agent deployments?
- What is the difference between converged identity governance and separate IGA and PAM tools?
