Because procurement reduces friction in buying access, but it does not resolve who approves trust, who rotates credentials, or who removes obsolete certificates when services change. If those operational decisions stay fragmented, the organisation may have easier access to tooling but weaker lifecycle control.
Why procurement helps, but governance still breaks down
Shared PKI procurement usually solves the commercial problem, not the control problem. A central buying model can standardise vendor selection, pricing, and service onboarding, but it does not decide who owns trust policy, who can approve certificate use, or which team is accountable when a certificate outlives the service it protects. Governance gaps appear when those decisions stay local, implicit, or undocumented.
That split matters because PKI is not just a product category. It is an operating model for trust, and the trust model must be defined as carefully as the tooling. If multiple teams rely on the same procurement channel but follow different rules for issuance, approval, renewal, revocation, and exception handling, the organisation gets consistency in purchasing without consistency in control.
Shared buying can also hide variation in certificate purpose. A certificate used for internal service authentication, public TLS, code signing, or an integration token may sit under the same procurement umbrella, yet each one carries different lifecycle expectations and blast-radius concerns. A procurement function can reduce friction, but it cannot substitute for clear ownership of those control decisions.
Where the governance gap actually appears
The gap usually shows up at handoff points. One team buys the platform, another team requests issuance, a third team runs the service, and no single function owns the full lifecycle from approval to retirement. That creates ambiguity over who can authorise trust, who validates the business need, and who removes certificates when an application is decommissioned or re-architected.
Renewal is often the first visible failure point. If ownership is unclear, certificates may be renewed by habit instead of by review, which keeps obsolete trust paths alive. If revocation is slow or inconsistent, stale certificates can remain valid after a service changes ownership, moves environment, or stops being used. Good procurement does not fix that; governance must define the decision rights and the evidence required at each step.
Shared procurement can also flatten important differences between environments. A platform team may centralise the purchasing channel while local teams still maintain separate issuance practices, key storage approaches, and exception approvals. The result is a fragmented control plane behind a unified vendor contract. In practice, the organisation has one supplier relationship, but many governance models.
A useful way to think about this is that procurement answers “how do we acquire the capability?” while governance answers “who is allowed to create, approve, change, and retire trust?” Those are related questions, but they are not the same control.
How to close the control gap without losing procurement efficiency
The fix is to pair the shared procurement layer with explicit lifecycle ownership. Contracting should be tied to control ownership, with named approvers for issuance policy, renewal policy, revocation authority, and certificate retirement. Without those assignments, the central buying model can actually delay accountability by making everyone assume someone else owns the operational decision.
Lifecycle standards should be specific enough that teams can execute them consistently. That means defining when certificates must be rotated, what events trigger revalidation, how quickly obsolete certificates are removed, and which exceptions require review. For certificate-heavy environments, Machine Identity, PKI and Certificate Lifecycle Guide is the clearest internal reference for the operational side of this problem.
Procurement teams also need a governance signal, not just a purchasing checklist. If the buying process does not require the service owner, trust owner, and rotation owner to be identified before rollout, the organisation is likely to accumulate certificates that are technically valid but operationally unmanaged. That is the point where ease of acquisition starts to undermine trust hygiene.
When certificate management depends on shared platforms or shared vendors, the team should verify that renewal and revocation are actually being driven by asset ownership rather than by calendar reminders alone. A contract can standardise service levels, but only governance can ensure that expired business use is reflected in certificate retirement. The external reference most directly aligned to that lifecycle discipline is NIST SP 800-57 Key Management.
Risk and Threat Considerations
Shared PKI procurement can create a false sense of control. The organisation may believe it has centralised trust because it has centralised purchasing, while the real failure lies in fragmented approval, renewal, and revocation processes. That exposes services to stale certificates, unreviewed trust relationships, and delayed removal of credentials when systems change.
Failure mechanism: Procurement standardises buying, but not the operational decisions that govern certificate issuance, rotation, and retirement. When ownership is unclear, obsolete certificates remain in service and trust can persist beyond the business need that justified it.
Impact: Attackers and insiders gain more time to exploit stale trust paths, compromised certificates become harder to contain, and service changes can leave behind unmanaged authentication material that widens exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, CSA Cloud Controls Matrix and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | PKI certificate rotation and retirement depend on key lifecycle discipline. |
| Recommendation — Define certificate cryptoperiods, rotation triggers, and retirement rules to keep trust current. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | PKI procurement gaps are governance gaps over trust approval and lifecycle ownership. |
| Recommendation — Assign ownership for issuance, renewal, and revocation across the certificate lifecycle. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Shared PKI needs clear accountability for trust decisions and service ownership. |
| PR.AA-05 — Identity Management, Authentication, and Access Control | Certificates are authentication material that must be governed through lifecycle controls. | |
| Recommendation — Define who owns trust policy and certificate lifecycle decisions in the operating model. Enforce lifecycle controls for certificate-based authentication materials. | ||
| ISO/IEC 27001:2022 | A.5.2 — Information security roles and responsibilities | PKI governance gaps stem from unclear responsibility for trust and certificate operations. |
| Recommendation — Assign and document responsibility for certificate approval, renewal, and revocation. | ||
Practitioner Guidance
What to verify: Confirm that every certificate has a named business owner, an operational owner, and a defined revocation path. If the organisation cannot show who approves issuance and who removes the certificate at end of life, the governance model is incomplete even if procurement is centralised.
What good looks like: Shared procurement should produce a consistent approval workflow, but each certificate class should still have explicit lifecycle rules, renewal triggers, and retirement criteria. The best sign of maturity is that teams can explain why a certificate exists, who is accountable for it, and what event will remove it.
Common mistake: Treating vendor consolidation as control consolidation. A single procurement channel does not eliminate fragmented trust decisions, and it can mask them until a renewal failure or decommissioning event exposes the gap.
Practitioner takeaway: Central purchasing improves standardisation only when it is paired with explicit trust ownership, otherwise the organisation buys PKI more efficiently while governing it less effectively.
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 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org