Centralise when certificate ownership is fragmented, validation credentials are spread across many hosts, or no one can confidently inventory what exists and when it expires. At that point, distributed manual handling is already the risk. A central lifecycle control plane gives you a single place to enforce policy and detect failure.
Why This Matters for Security Teams
Certificate operations stop being a narrow platform task once ownership fragments across Kubernetes, CI/CD, edge devices, and internal applications. At that point, expiry, renewal, and revocation become enterprise reliability issues, not just PKI hygiene. NIST Cybersecurity Framework 2.0 frames identity and access as a core governance concern, and NHIMG research shows the operational reality: SailPoint’s machine identity management report found 57% of organisations lack a complete inventory of their machine identities.
That lack of inventory is the real tipping point for centralisation. If teams cannot confidently say what certificates exist, where they are installed, who owns them, and which ones are near expiry, distributed management is already failing. Centralisation is not about bureaucracy. It is about establishing a lifecycle control point that can enforce policy, reduce manual work, and prevent outages caused by missed renewal windows. In practice, many security teams only discover the need for central control after a certificate outage has already interrupted production traffic.
How It Works in Practice
The decision to centralise should be based on operational signals, not organisational preference. Current guidance suggests centralising when certificate issuance and renewal depend on shared validation assets, when teams track certificates in spreadsheets, or when service owners cannot independently prove expiry dates and ownership. NHIMG’s Ultimate Guide to NHIs notes that 61% still rely on spreadsheets or manual tracking for machine identity management, which is a strong indicator that the control plane needs to move upstream.
In practice, centralisation usually means one of three models:
- A central PKI or certificate lifecycle platform issues and renews certificates for many teams.
- A shared control plane manages policy, while platform teams retain operational ownership of deployment.
- A hybrid model centralises issuance and telemetry, but delegates local installation for specialised systems.
Security teams should look for the point where the cost of coordination exceeds the cost of standardisation. If renewal logic differs by application, if validation keys are duplicated across hosts, or if nobody can automate revocation consistently, centralising the lifecycle becomes the safer option. That control plane should integrate with inventory, policy-as-code, alerting, and secrets management so certificate expiry is visible before it becomes an incident. NIST’s Cybersecurity Framework 2.0 supports this kind of governance-driven approach by tying asset visibility and risk management to operational controls. These controls tend to break down in highly federated environments where each business unit runs its own PKI tooling and refuses a common inventory standard because ownership boundaries stay unclear.
Common Variations and Edge Cases
Tighter central control often increases coordination overhead, requiring organisations to balance standardisation against local autonomy. That tradeoff matters most in environments with air-gapped systems, regulated industrial controls, or subsidiaries with separate operational mandates. In those cases, full centralisation may be unrealistic, and the better answer is shared governance with local execution. Best practice is evolving here, and there is no universal standard for how much certificate authority should be centralised versus delegated.
Edge cases also appear when ephemeral workloads generate large volumes of short-lived certificates. Centralising policy and telemetry is usually useful, but forcing every renewal through a manual approval path can create bottlenecks and reduce availability. In those environments, central teams should define issuance policy, TTL limits, and emergency revocation procedures, while automation handles routine lifecycle events. NHIMG has repeatedly shown how hidden credential sprawl becomes a failure driver, including cases such as JetBrains GitHub plugin token exposure and Code Formatting Tools Credential Leaks, where unmanaged secrets and poor visibility amplified risk. The practical rule is simple: centralise the lifecycle when visibility, ownership, or expiry discipline is weak; keep local execution only where automation and auditability remain strong.
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 CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Central inventory and ownership are core to deciding when to centralise. |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory maturity determines whether decentralised handling is still viable. |
| CSA MAESTRO | SG-02 | Agentic and workload governance needs central policy for identity lifecycle decisions. |
| NIST AI RMF | GOVERN | Governance is needed to assign accountability for automated identity operations. |
Centralise lifecycle control when inventory gaps prevent reliable certificate ownership and expiry tracking.
Related resources from NHI Mgmt Group
- How can organisations decide when certificate-based authentication is worth the effort?
- How do organisations decide whether to centralise or decentralise secrets control?
- How can organisations govern AI agents without slowing operations?
- Should organisations treat certificate expiry as an operational risk or a security risk?
