Applications that rely on self-signed certificates sit outside the trust model established by enterprise PKI. That creates weak assurance, harder revocation, and more difficulty proving whether the certificate has a valid business purpose. Teams should discover those applications, decide whether they are still needed, and replace untrusted certificates with properly issued ones where appropriate.
Why Self-Signed Certificates Break the Enterprise Trust Model
Self-signed certificates can work as an isolated mechanism, but they do not inherit the assurance properties of an enterprise PKI. That means the application is deciding trust locally instead of relying on a governed certificate authority, a defined identity lifecycle, and revocation processes that security teams can actually operate at scale.
For practitioners, the key issue is not just “is the certificate encrypted?”, but “who vouches for it, how is it renewed, and how is it removed when trust changes?” Enterprise PKI gives you a control plane for those questions, while self-signed certificates leave each application to improvise its own trust decision.
That is why enterprise PKI is materially different from an ad hoc certificate swap. A properly issued certificate can be anchored in a CA hierarchy, traced to a purpose, and managed through the same lifecycle expectations as other identity-bearing material. A self-signed certificate has no external attestation path, so it cannot easily prove that it belongs to a legitimate business service rather than a convenient shortcut.
What Operational and Security Problems Follow
The first breakage is assurance. When the application trusts a self-signed certificate, it cannot rely on the normal chain of trust, which weakens confidence in the endpoint, the service, and the identity behind the connection. The second breakage is revocation, because enterprise PKI gives you a way to invalidate trust centrally, while self-signed certificates are usually found late, replaced inconsistently, or left in place until failure forces attention.
That creates a management problem as much as a cryptographic one. Teams lose visibility into where certificates live, whether they are still needed, and whether the certificate presented by a service has a legitimate business purpose. The result is a patchwork trust estate where exceptions accumulate, auditing gets harder, and the organisation cannot distinguish deliberate exceptions from forgotten technical debt.
Self-signed usage also encourages shadow trust. Applications may continue to function even after the environment has moved to enterprise PKI, which means the insecure path quietly survives alongside the approved one. In practice, that undermines standardisation, complicates certificate rotation, and makes it harder to enforce consistent policies across environments and deployment pipelines.
How to Replace Ad Hoc Trust with a Managed Certificate Lifecycle
The practical fix is to inventory where self-signed certificates are still used, confirm which applications genuinely need them, and replace them with certificates issued from the approved enterprise PKI wherever possible. Machine Identity, PKI and Certificate Lifecycle Guide is the right internal starting point when you need the lifecycle view, because the breakage here is as much about renewal, expiry and governance as it is about cryptography.
Where the application is a service or workload rather than a human-facing system, treat the certificate as part of the machine identity lifecycle, not as a one-off configuration file. Guide to SPIFFE and SPIRE is useful for understanding how trust bundles, attestation and workload identity can replace brittle local trust decisions with something operationally managed.
Use enterprise PKI to enforce ownership, renewal, and retirement decisions. If a certificate is still required, it should be issued, monitored, and rotated under an accountable process; if it is only there because an application was never modernised, that is a decommissioning or remediation task, not a certificate preference.
Risk and Threat Considerations
Self-signed certificates create a trust gap that can hide both accidental misuse and malicious substitution. When clients accept locally trusted certificates, an attacker who can influence configuration, deployment, or DNS-adjacent trust decisions has more room to impersonate a service, persist unnoticed, or keep an unauthorised connection alive after the environment should have rejected it.
Failure mechanism: The organisation loses a central trust anchor, so revocation, assurance, and certificate ownership become inconsistent across applications. That weakens the ability to prove which endpoints are legitimate and makes stale trust harder to remove.
Impact: Attackers and internal misconfigurations both benefit from the same blind spot, because trust decisions are local, exceptions spread, and expired or unauthorised certificates can continue to function longer than intended.
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 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 | Certificate trust depends on key lifecycle, rotation, and retirement. |
| Recommendation — Manage certificate keys with defined lifecycle, rotation, and destruction rules. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates function as authenticators that need issuance, renewal, and revocation control. |
| IA-9 — Service Identification and Authentication | Self-signed certificates often secure service-to-service trust and need managed authentication. | |
| Recommendation — Enforce lifecycle controls for certificates used to authenticate systems. Use managed service authentication instead of unmanaged self-signed trust. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Certificate trust depends on governed identities and ownership of services. |
| Recommendation — Assign ownership and lifecycle control to every certificate-bearing service. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticators are managed commensurate with the risk associated with the use of the authenticator and life cycle of the associated identities. | Certificates are authenticators whose lifecycle and risk must be managed. |
| Recommendation — Manage certificate authenticators according to their risk and lifecycle. | ||
Practitioner Guidance
What to verify: Confirm whether each self-signed certificate is genuinely needed for a controlled exception, or whether it is just a legacy default that survived deployment. If the service has an owner, a renewal path, and an external trust requirement, it should usually be on enterprise PKI.
Decision rule: If the certificate participates in production trust, treat replacement and revocation handling as higher priority than cosmetic hardening. If the certificate is only for ephemeral local testing, isolate it from production trust paths and make sure it cannot be confused with approved identity material.
Practitioner takeaway: The important question is not whether a self-signed certificate “works”, but whether the organisation can govern trust, prove purpose, and remove it safely when that trust is no longer justified.
Related resources from NHI Mgmt Group
- What breaks when developers keep long-lived SSH keys and secrets in local configuration instead of a managed workflow?
- What happens when employees keep using unauthorized software instead of approved tools?
- What breaks when AI is bolted onto existing applications instead of using AI-first architecture?
- What breaks when OT teams rely on self-signed or reused certificates?
