A certificate that covers a primary domain and all of its first-level subdomains. It simplifies administration, but it also increases blast radius because one key and one trust object can authenticate many services, making key protection and scope review especially important.
Expanded Definition
A wildcard certificate is a TLS certificate whose subject alternative coverage includes a primary domain and any first-level subdomain beneath it, such as api.example.com and login.example.com. In NHI and workload security, it is best understood as a shared trust object that compresses administrative overhead while concentrating risk.
Definitions vary across vendors on how broadly the operational scope should be treated, but the security concern is consistent: one private key can unlock many services, making compromise or misissuance disproportionately impactful. That is why NHI Management Group treats wildcard certificates as a governance issue, not just a certificate-format choice, especially when they are used with service accounts, CI/CD pipelines, or internal APIs. For a standards-oriented security baseline, map their handling to the NIST Cybersecurity Framework 2.0 concepts of asset visibility, access control, and recovery discipline.
The most common misapplication is treating a wildcard certificate as a harmless convenience layer when it is actually deployed across unrelated workloads that should have been isolated by key, trust boundary, or revocation path.
Examples and Use Cases
Implementing wildcard certificates rigorously often introduces a blast-radius tradeoff, requiring organisations to weigh simpler issuance and renewal against the cost of broader key exposure and more difficult incident containment.
- A platform team uses one wildcard certificate for NHIs across development subdomains, reducing renewal work but demanding strict private-key storage and rotation discipline.
- An internal API gateway terminates TLS with a wildcard certificate so that new first-level services can be added quickly without requesting a new certificate for each hostname.
- A CI/CD environment deploys ephemeral test services under many subdomains, using one wildcard certificate to avoid certificate sprawl while still enforcing short-lived build credentials.
- A security team reviews whether a certificate should instead be split by application domain after reading the Sisense breach case pattern, where broader identity exposure can amplify downstream impact.
- A certificate management workflow aligns renewals with ACME-style automation and checks revocation readiness, using guidance from NIST Cybersecurity Framework 2.0 to keep ownership and recovery visible.
Why It Matters in NHI Security
Wildcard certificates matter because they collapse many authentication points into one trust anchor, which means a single leaked key can expose multiple services at once. That concentration is especially dangerous in environments where secrets already drift into code, config files, or CI/CD systems. In the Ultimate Guide to NHIs, NHI Management Group notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 97% of NHIs carry excessive privileges, conditions that make a shared certificate key even harder to defend.
That risk is not theoretical: the SailPoint research on machine identity management reports that 53% of organisations have experienced a security incident directly related to machine identity management failures, and certificate expiry is the leading cause of outages for 45% of organisations in that study. In practice, wildcard certificates become a governance problem when inventory, key protection, and renewal ownership are unclear, not just when cryptography is weak. Organisational teams typically encounter the operational cost of a wildcard certificate only after a key leak, service outage, or emergency reissue forces every dependent workload to be touched at once.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Wildcard certs are shared secrets that expand blast radius across workloads. |
| NIST CSF 2.0 | PR.AC-1 | Access control and asset visibility are central to limiting wildcard certificate exposure. |
| NIST Zero Trust (SP 800-207) | Zero trust discourages broad implicit trust created by one certificate spanning many services. |
Inventory wildcard certificates, restrict key access, and rotate them as high-risk shared NHI assets.
Related resources from NHI Mgmt Group
- How should teams manage shrinking certificate lifecycles in NHI environments?
- What is the difference between certificate management and NHI governance?
- Should organisations treat certificate expiry as an operational risk or a security risk?
- How should security teams govern certificate lifecycles across hybrid environments?
