How do organisations decide between wildcard certificates and individual certificates for subdomains?

Choose wildcard certificates when many first-level subdomains share the same owner, lifecycle, and risk profile. Choose individual certificates when applications need stronger separation, different validation, or tighter blast-radius control. The right decision depends on governance, not convenience alone. Teams should align certificate design with operational responsibility, security boundaries, and renewal processes.

Why This Matters for Security Teams

Wildcard and individual certificates look like a simple packaging choice, but they change how trust is distributed across subdomains, teams, and release cycles. A wildcard can reduce operational overhead when many first-level subdomains are genuinely identical in ownership and exposure. Individual certificates, by contrast, give security teams sharper separation when one app should not inherit another app’s risk. That distinction matters because certificate scope often becomes part of the blast radius.

Security leaders should treat this as a governance decision, not just a renewal convenience. The practical question is whether a single private key can safely represent multiple services, or whether one compromise would be too costly. This is especially important in environments already struggling with secrets sprawl, where NHIMG research on The State of Secrets in AppSec highlights how fragmented secrets management makes central control harder to sustain. NIST guidance on asset and identity governance in the NIST Cybersecurity Framework 2.0 reinforces the same principle: scope should match risk, not convenience.

In practice, many security teams discover certificate scope misalignment only after a shared key has already become the easiest path for lateral movement or emergency renewal chaos.

How It Works in Practice

The decision starts with ownership. If multiple subdomains belong to one product team, share the same deployment pipeline, and follow the same rotation process, a wildcard certificate can be reasonable. If the subdomains map to different applications, business units, vendors, or data classifications, individual certificates usually provide better containment. The key issue is not whether the certificate is technically valid for the hostname. It is whether the trust boundary is acceptable.

Operationally, teams should evaluate:

• Who controls the private key and where it is stored
• Whether every covered subdomain has the same patching and release cadence
• How renewal is automated and who is responsible for failures
• Whether one subdomain compromise would expose unrelated services
• Whether certificate transparency, monitoring, and revocation are already in place

Wildcard certificates are often chosen to simplify provisioning for ephemeral environments, shared platforms, or large fleets of low-risk subdomains. Individual certificates are better when teams need tighter blast-radius control, clearer audit trails, or different validation methods for different properties. NIST’s identity guidance in NIST Cybersecurity Framework 2.0 supports that kind of risk-based segmentation, while NHIMG research such as Sisense breach shows how a single exposed secret can become systemic when access scope is too broad. In mature environments, the certificate strategy is usually tied to service ownership and secrets handling, not to the number of hostnames alone. These controls tend to break down when many teams share one certificate but operate on different release and incident-response timelines.

Common Variations and Edge Cases

Tighter certificate scoping often increases operational overhead, requiring organisations to balance reduced blast radius against renewal complexity and key management burden. That tradeoff becomes more visible in large cloud estates, staging fleets, and customer-specific tenant subdomains.

Current guidance suggests that wildcard certificates are a poor fit when:

• subdomains have different owners or vendors
• one service is public-facing and another is internal
• separate compliance or audit requirements apply
• the same private key would have to be distributed widely

Individual certificates are also preferred when organisations need cleaner certificate revocation, clearer forensic attribution, or different validation strength per workload. That said, there is no universal standard for when wildcard usage becomes unacceptable. Best practice is evolving toward smaller trust domains, stronger automation, and precise inventory of which services rely on which keys. For teams already dealing with certificate sprawl, the real question is whether the certificate model helps security operations move faster without broadening shared failure points. NHIMG’s Ultimate Guide to NHIs is a useful reference for understanding how identity scope and secret scope should stay aligned. The practical limit is reached when one certificate starts representing unrelated risk domains, because renewal convenience then becomes a hidden dependency across too many systems.

Related resources from NHI Mgmt Group

• How do organisations decide between browser-first and broader AI governance controls?
• How do organisations decide between self-hosted open-weight models and hosted APIs?
• How should organisations decide between federated authentication and SSO?
• How do organisations decide between unified access control and point solutions?