Accountability should sit with the team that owns PKI policy and operational oversight, even if issuance and maintenance are shared across infrastructure, application, and device teams. Centralisation does not remove responsibility. It makes it easier to define roles, permissions, approval flows, and audit evidence so every action is traceable to an owner.
Why This Matters for Security Teams
When certificate management is centralised across platform, application, and device teams, the main risk is not duplication of effort. It is unclear accountability. PKI failures rarely present as a single technical fault; they show up as expired certificates, unmanaged issuance, weak approval paths, or undocumented exceptions that no one owns. That is why governance matters as much as operational handling. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is explicit that auditability and ownership must remain traceable even when execution is distributed.
Security teams often assume centralisation solves control sprawl, but centralisation without policy ownership can actually hide it. The organisation may have a shared certificate platform, yet no single authority defining certificate standards, issuance approval, renewal thresholds, or emergency revocation rules. The result is fragmented decision-making with a false sense of order. NIST’s Cybersecurity Framework 2.0 reinforces that governance is a leadership function, not just an operations function. In practice, many security teams discover the ownership gap only after a certificate outage or audit finding has already exposed it.
How It Works in Practice
The cleanest model is to separate policy authority from execution responsibility. One team, usually security or a pki governance function, owns the rules: certificate profiles, key lengths, trust chains, approval criteria, renewal SLAs, revocation standards, and exception handling. Other teams can issue, deploy, or renew within those rules, but they do not redefine them ad hoc. That division keeps accountability intact while still allowing operational scale.
Practically, this means every certificate workflow should map to an owner, a control, and an evidence trail. Shared tooling helps, but tooling is not governance. A central PKI service should enforce role-based permissions, approval workflows, logging, and periodic access review. The operational teams responsible for infrastructure, applications, and devices can each hold scoped privileges, but those privileges should be derived from the PKI policy owner’s rules, not negotiated informally per project. This is where certificate lifecycle management becomes essential, and NHIMG’s NHI Lifecycle Management Guide is useful because it frames issuance, rotation, renewal, and revocation as governed lifecycle events rather than isolated tasks.
Strong governance also depends on metrics. Teams should be able to answer who approved issuance, where the private key is stored, what the renewal threshold is, and how quickly revocation happens after compromise or role change. Centralisation reduces variation, but it does not eliminate the need for documented exceptions. The practical benchmark is simple: a certificate should be traceable from policy to approval to deployment to retirement. For a broader risk lens, the Top 10 NHI Issues highlights how poor lifecycle control and weak ownership repeatedly surface in identity failures. These controls tend to break down when multiple teams can independently request exceptions in large, fast-moving environments because no single owner can enforce consistent renewal and revocation discipline.
Common Variations and Edge Cases
Tighter PKI governance often increases coordination overhead, requiring organisations to balance control against delivery speed. That tradeoff is real, especially in DevOps, MDM, and IoT environments where certificates must be issued quickly and at scale. Current guidance suggests central policy with delegated execution is the most sustainable pattern, but there is no universal standard for exactly how much authority should be delegated to each domain team.
In highly regulated environments, the PKI owner may sit within security, while infrastructure teams operate subordinate issuance systems and application teams manage certificate deployment. In cloud-native environments, service owners may trigger issuance through automation, but the policy owner still defines acceptable cryptographic standards and renewal intervals. The edge case to watch is emergency remediation: if every team can bypass controls during an outage, governance becomes symbolic. The better pattern is break-glass access with mandatory logging, time limits, and after-action review. NIST SP 800-53 Rev. 5 supports this kind of control mapping by tying access, audit, and configuration discipline to accountable owners. Where organisations struggle most is in federated estates with legacy CAs, because inconsistent tooling and overlapping approval paths make policy enforcement harder than the governance model suggests.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | PKI governance is an oversight function that needs accountable ownership. |
| NIST SP 800-63 | Certificate assurance depends on identity proofing, binding, and lifecycle control. | |
| NIST Zero Trust (SP 800-207) | Centralised certificate governance supports strong trust boundaries and least privilege. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Central certificate ownership reduces unmanaged non-human identity sprawl. |
| NIST AI RMF | GOVERN | Governance principles apply to shared operational control with clear accountability. |
Assign a governance owner for PKI policy, review exceptions, and track certificate risk through oversight reporting.
Related resources from NHI Mgmt Group
- How should security teams evaluate privileged access management before deploying it across human, machine, and certificate identities?
- Who is accountable for identity governance outcomes when a global rollout spans multiple regions and teams?
- How should security teams streamline certificate profile management across PKI workflows?
- What breaks when identity governance is split across consulting, implementation, and managed service teams?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
