Why do organisations with growing certificate estates need more than basic CA functionality?

Why This Matters for Security Teams

Basic CA functionality answers a narrow question: can a certificate be issued and signed correctly? It does not answer the operational questions that matter at scale, such as who owns the certificate, where it is deployed, when it expires, and whether policy is still being followed after issuance. That gap becomes expensive once certificates span applications, cloud accounts, CI/CD pipelines, appliances, and third-party trust domains. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that cryptographic trust is only one part of a broader governance problem.

NHIMG research shows why this is no longer a niche issue. In Ultimate Guide to NHIs — What are Non-Human Identities, the data shows that 71% of NHIs are not rotated within recommended time frames and only 5.7% of organisations have full visibility into their service accounts. Those are the conditions under which “working CA” becomes “failed trust program.” In practice, many security teams encounter certificate outages only after expiry has already broken production systems, rather than through intentional lifecycle control.

How It Works in Practice

Organisations with growing certificate estates need capability beyond issuance because the real risk sits in the lifecycle. Mature certificate management adds discovery, ownership mapping, policy enforcement, renewal orchestration, revocation handling, and audit evidence. That is the difference between a CA as a signing service and a certificate program as an operational control plane. For certificate-heavy environments, the control plane needs to know what exists, where it is deployed, which trust domain it belongs to, and whether it is still compliant with internal policy.

Practically, this usually means integrating the CA with inventory and automation systems rather than treating it as a standalone tool. Renewal should be event-driven and automated where possible. Expiry windows need alerting that is tied to service ownership, not just generic notifications. Policy should be enforced at issuance and during renewal, with different rules for public-facing TLS, internal service-to-service certificates, device identities, and partner-managed trust chains. NIST’s guidance on access control and system integrity supports this approach, but current guidance suggests organisations should adapt the workflow to their own trust boundaries instead of assuming one CA process fits every environment.

• Discover certificates continuously across clouds, platforms, appliances, and embedded systems.
• Assign ownership so every certificate has a named accountable team.
• Automate renewal and revocation, especially for short-lived and high-volume certificates.
• Apply policy consistently across trust domains rather than per-team exceptions.
• Track certificate usage, expiry, and deployment drift as part of operational monitoring.

NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities highlights the broader NHI problem: secrets and machine credentials often outlive the systems they protect, and unmanaged validity windows become an attack path. These controls tend to break down when certificates are distributed across legacy platforms that cannot support automated renewal because manual exceptions reintroduce outage risk.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead at first, requiring organisations to balance stronger control against legacy compatibility and deployment friction. That tradeoff is most visible in environments with mainframes, industrial systems, or third-party-managed services where automation is limited and renewal windows are hard to coordinate. Best practice is evolving, but there is no universal standard for this yet across all certificate estates.

Public TLS, internal mTLS, device certificates, and code-signing certificates do not behave the same way, so a single policy model can fail if it ignores those differences. For example, a short-lived certificate strategy may work well for service-to-service authentication but be inappropriate for a device that only connects intermittently. Similarly, a CA can be technically reliable while the broader trust program still fails because ownership is unclear or revocation is not operationalised. That is why basic CA features are necessary but not sufficient.

The clearest lesson from NHIMG research is that visibility and lifecycle control matter more than certificate count alone. The Sisense breach is a reminder that machine identity exposure can become a business issue when secrets and trust material are poorly governed. Security teams should treat certificate growth as a governance signal, not just a capacity issue.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?