In-house PKI means the organisation runs the certificate infrastructure, policies, and lifecycle operations itself. Managed PKI shifts much of that operational burden to a provider while preserving control over issuance, renewal, and revocation policy. The practical difference is usually expertise, scale, and overhead. Managed approaches reduce staffing pressure, but governance still remains with the enterprise.
How in-house PKI and managed PKI divide responsibility
They differ mainly in operating model. In-house PKI keeps certificate authorities, policy enforcement, renewal workflows, and incident response inside the organisation. Managed PKI outsources much of that day-to-day operation to a provider, but the enterprise still owns the trust decisions that matter: who can issue, what can be issued, when it expires, and how revocation works.
The practical boundary is not “control versus no control,” but “control over policy versus control over operations.” That distinction matters because PKI is both a security control and a service function. Organisations often choose managed PKI to reduce infrastructure burden, but they keep in-house ownership when they need tighter integration with internal systems, custom policy enforcement, or stronger sovereignty over keys and issuance workflows.
For certificate lifecycle specifics, the issue is not only issuance. Renewal, revocation, expiry handling, auditability, and crypto agility are all part of the operating model. The Machine Identity, PKI and Certificate Lifecycle Guide is useful background on why lifecycle discipline becomes a core operational concern once certificates are used at scale.
What changes in practice when you outsource PKI operations
Managed PKI usually changes staffing, process ownership, and failure handling more than it changes the security objective. The provider may run the platform, automate renewal, and maintain the CA infrastructure, while your team still decides trust hierarchy, issuance rules, approval workflows, and what counts as a valid identity for certificate issuance.
That shift reduces overhead, especially where there are many short-lived certificates or limited PKI expertise. It can also improve consistency if the provider offers strong automation and monitoring. The trade-off is dependency: you inherit the provider’s availability, support quality, revocation responsiveness, and control-plane resilience. If the provider fails, renewal may fail before expiry becomes visible to business systems.
In-house PKI gives deeper local control but also concentrates operational risk inside the enterprise. Teams must maintain CA hardening, backup and recovery, key protection, renewal automation, and audit evidence themselves. That model can be appropriate when certificate policy is highly specific, but it only works well if the organisation can sustain the specialist skills and process discipline required.
Certificate lifecycle and key handling are central to both models, which is why NIST SP 800-57 Key Management is directly relevant. It frames the lifecycle and cryptoperiod decisions that still need governance even when operations are outsourced.
How to choose the right PKI model for your environment
The right choice usually depends on scale, expertise, regulatory exposure, and the degree of custom trust control you need. In-house PKI tends to fit organisations with mature security engineering teams, strict internal policy requirements, or environments where certificate issuance must be tightly integrated with internal identity and infrastructure systems.
Managed PKI tends to fit organisations that need faster operational scaling, lower certificate-management overhead, or a way to reduce the risk of manual renewal failures. It is often a better fit when the main challenge is execution, not policy design. If the enterprise already knows the trust model it wants, but does not want to run CA operations itself, managed PKI is usually the more practical path.
The decision should also account for trust boundaries outside the enterprise. Publicly trusted certificates, revocation expectations, and baseline issuance requirements are governed by ecosystem rules, not just internal preference. The CA/Browser Forum is the key external reference when the certificate program relies on public trust and browser acceptance.
Risk and Threat Considerations
PKI failures are rarely about the certificate authority alone. The bigger risks are expired certificates, weak revocation handling, exposed private keys, and unclear ownership when a provider or internal team assumes the other side is watching expiry or incident response. Those failures can disrupt services, break trust chains, or leave stolen credentials valid longer than intended.
Failure mechanism: The control breaks when certificate lifecycle ownership, revocation responsiveness, or key protection is ambiguous, automated poorly, or dependent on a third party that cannot react quickly enough to an outage or compromise.
Impact: The result can be service outage, failed authentication, broken mutual TLS, or prolonged trust in a compromised certificate or key, especially where certificate expiry or revocation is not continuously monitored.
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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | PKI choice directly affects certificate and key lifecycle governance. |
| Recommendation — Define cryptoperiods, rotation, and destruction rules for every CA and certificate class. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | PKI depends on managing certificate and key authenticators across their lifecycle. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Certificate-based trust often authenticates services and external systems through PKI. | |
| Recommendation — Automate certificate issuance, renewal, rotation, and revocation under controlled procedures. Use certificate-based authentication controls for non-organizational entities that need trusted access. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | PKI is a cryptographic trust service whose operation must be governed and protected. |
| Recommendation — Document and enforce approved cryptographic use, key handling, and certificate governance. | ||
| CIS Controls v8 | CIS-5 — Account Management | PKI lifecycle depends on controlling issuance and revocation for certificate-bearing accounts. |
| Recommendation — Inventory certificate-bearing identities and remove or rotate access when ownership changes. | ||
Practitioner Guidance
What to verify: Before choosing a managed model, verify exactly who owns issuance policy, revocation decisions, key custody, renewal automation, and audit evidence. If any one of those is vague, the operating model is not mature enough to trust.
Decision rule: If your main pain point is operational overhead and you can tolerate provider dependency, managed PKI is usually the simpler path. If your trust model is highly bespoke, the certificate estate is tightly tied to internal infrastructure, or you need full control over CA operations, in-house PKI is the safer fit.
Practitioner takeaway: The real decision is not whether certificates are “owned” internally or externally, but whether the organisation can prove continuous control over lifecycle, revocation, and key protection in the model it chooses.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
