How should security teams manage wildcard certificates across first-level subdomains in larger web environments?

Why This Matters for Security Teams

Wildcard certificates look simple, but in larger web environments they become a governance decision, not just a TLS convenience. A single certificate that covers many first-level subdomains can reduce operational overhead, yet it also expands blast radius if the private key is exposed, reused too broadly, or poorly tracked across teams. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need to manage cryptographic material with disciplined access, lifecycle, and revocation controls.

That matters because certificate sprawl often appears as routine infrastructure growth: new brands, regions, tenants, or application tiers each inherit the same wildcard pattern until ownership becomes unclear. NHIMG’s NHI Lifecycle Management Guide treats issuance and renewal as lifecycle events, not one-off admin tasks, which is the right lens for certificate governance too. When wildcard scope drifts away from the actual trust boundary, teams lose the ability to answer a basic question: which subdomains are protected by the same key, and who can rotate it safely? In practice, many security teams discover that mismatch only after an expired cert or leaked private key has already affected multiple production services.

How It Works in Practice

Security teams should manage wildcard certificates by tying each certificate to a clearly defined ownership domain, then centralising issuance, renewal, inventory, and revocation under that owner. A wildcard for

*.example.com

is appropriate only when the subdomains share the same trust boundary, deployment model, and response process. If one subdomain hosts a customer portal and another hosts internal admin tooling, the shared certificate is usually too coarse.

Operationally, good practice is to maintain a live inventory of where each certificate is deployed, who approves renewal, and what automation handles replacement. The certificate should be stored and rotated like any other sensitive secret, with restricted access and short-lived exposure windows. Where possible, automate renewal through a controlled pipeline rather than manual change windows, because expired wildcards cause broad outages fast. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because the same lifecycle discipline used for NHI credentials applies to certificate issuance, rotation, and revocation.

• Use one wildcard per shared trust boundary, not per convenience cluster.
• Restrict private key access to the smallest possible operator group.
• Track certificate-to-subdomain mappings in inventory and CI/CD controls.
• Prefer automation for renewal, validation, and rollback to reduce outage risk.
• Split certificates when validation, ownership, or incident response differs.

For auditability, teams should also align logging and change records so certificate changes are attributable. NIST’s NIST Cybersecurity Framework 2.0 supports this approach through asset management, protective controls, and recovery planning. These controls tend to break down when wildcard certificates are issued ad hoc by multiple platform teams because no single inventory or revocation path exists.

Common Variations and Edge Cases

Tighter certificate scoping often increases operational overhead, requiring organisations to balance isolation benefits against renewal complexity and change-management load. That tradeoff is real, especially in environments with frequent subdomain creation, M&A integrations, or many short-lived application stacks. Best practice is evolving, but the current guidance suggests that the more distinct the business function, compliance boundary, or deployment owner, the less appropriate a shared wildcard becomes.

There are also cases where wildcard use should be limited even if the subdomains are technically related. For example, a shared certificate may be acceptable for a homogeneous SaaS fleet, but less suitable where distinct services require separate keys, customer-specific controls, or differentiated incident response. Teams should be cautious with load balancers, service meshes, and CDN layers that mask the real certificate placement, because that can hide where the private key actually lives. NHIMG’s Top 10 NHI Issues highlights how key and secret sprawl create governance gaps; the same pattern applies to certificates when ownership is fragmented.

If the environment uses automated cert issuance at scale, compare the control model against Ultimate Guide to NHIs — Regulatory and Audit Perspectives to ensure evidence of approval, rotation, and revocation exists. In highly segmented or multi-tenant environments, a wildcard can become too broad to defend cleanly, even when it remains operationally convenient.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams make NHI best practices usable across the business?
• How should security teams manage identity architecture across complex environments?