Should organisations use wildcard or multi-year certificates as part of certificate lifecycle management?

Why This Matters for Security Teams

Certificate lifetime decisions are not just procurement choices. They determine how quickly an exposed key can be replaced, how much blast radius a single certificate covers, and how much confidence teams can place in ownership and revocation. Longer-lived certificates and wildcard coverage can make operations simpler, but they also make hidden dependencies harder to see. That matters most in environments where services are created and retired continuously, because stale trust can outlive the systems it was meant to protect.

NHIMG research shows why this becomes an operational issue fast: in The Critical Gaps in Machine Identity Management report, SailPoint found that 59% of companies face greater difficulties auditing machine identities due to unclear ownership and limited visibility. That is exactly the condition under which broad-scoped or long-lived certificates become risky. Guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both points toward tighter ownership, stronger lifecycle control, and least privilege for machine trust. In practice, many security teams encounter wildcard and multi-year certificate risk only after an outage, revocation gap, or ownership dispute has already occurred.

How It Works in Practice

The practical question is not whether wildcard or multi-year certificates are always good or bad. It is whether the organisation can prove ownership, scope, and replacement discipline throughout the certificate lifecycle. A wildcard certificate may be appropriate for a stable platform with many subdomains, but it creates a shared trust point: if the private key is exposed, every covered host inherits the same exposure. Multi-year certificates reduce renewal toil, but they also increase the time window in which mis-issuance, key compromise, and stale asset mapping can persist.

Security teams usually manage this with a combination of inventory, policy, and automation. The NHI Lifecycle Management Guide is a useful reference for the broader control problem because lifecycle discipline is what prevents certificates from becoming unowned trust artifacts. A strong operational pattern typically includes:

• Documenting the business owner, technical owner, and revocation path for every certificate.
• Limiting wildcard scope to cases where the blast radius is understood and accepted.
• Using shorter TTLs where automation can support renewal and replacement safely.
• Monitoring for certificate reuse across apps, environments, or teams.
• Rekeying after incidents, not just renewing on schedule.

For machine identity programs, the most important control is not renewal frequency alone but whether issuance and revocation are tied to service state. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets reinforces that static trust artifacts behave differently from dynamically issued ones, and certificates should be treated with the same discipline. These controls tend to break down when ownership is split across platform, application, and infrastructure teams because no single group can reliably retire or replace the certificate on time.

Common Variations and Edge Cases

Tighter certificate lifetimes often increase operational overhead, so organisations must balance security gains against renewal risk, automation maturity, and service criticality. Current guidance suggests that multi-year certificates are least defensible when revocation responsiveness is weak or when the inventory is incomplete. In those cases, extending validity does not reduce risk, it extends uncertainty.

There are a few common edge cases. Wildcards may be defensible for internal platforms where subdomains are ephemeral and centrally controlled, but they are a poor fit when different teams manage different services under the same domain. Multi-year certificates can be acceptable in low-change environments with strong automation, yet best practice is evolving toward shorter lifetimes for high-value workloads because compromise detection remains imperfect. NHIMG’s Top 10 NHI Issues and the Guide to the Secret Sprawl Challenge both reflect the same pattern: when identities and secrets multiply faster than governance, broad or long-lived credentials are usually the first place risk accumulates. The right answer is not a universal ban, but a policy that defaults to narrower scope and shorter validity unless the control environment can justify more.

Related resources from NHI Mgmt Group

• Should organisations use Honeytokens as part of secrets management?
• How should organisations govern SaaS access as part of lifecycle management?
• How should teams govern certificate lifecycle management in multi-cloud environments?
• How should organisations govern certificate lifecycle management for NIS2 and DORA?