A wildcard certificate secures multiple subdomains at one level, such as blog.examplecompany.com and mobile.examplecompany.com, under a single certificate. It does not cover deeper subdomains or the naked domain unless those are added separately. Full coverage requires deliberate certificate design so every public-facing name is authenticated and encrypted without gaps.
How wildcard coverage differs from full certificate coverage
A wildcard certificate is a convenience mechanism: one certificate can cover many first-level subdomains under the same parent name. That reduces operational overhead, but it also creates a single trust object with broader blast radius. Full certificate coverage is a design discipline, not a certificate type, and it means every public hostname is intentionally covered, including the bare domain and any deeper subdomains that users or systems can actually reach.
The practical difference is not just scope, it is control. Wildcards are easy to issue and renew, but they only authenticate names that fit the wildcard pattern. full coverage requires inventory discipline so you know which names exist, where they terminate, and whether any public endpoint is left outside the protection boundary. For certificate lifecycle discipline across machine and service identities, NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is a useful companion reference.
In healthcare environments, the distinction matters because subdomains often reflect different operational surfaces, such as patient portals, clinical systems, vendor integrations, mobile apps, and legacy services. A wildcard may cover several of them, but it does not guarantee coverage of every name that has been published over time. A full-coverage approach is stronger when an organisation needs to prevent any public-facing hostname from falling back to an expired, self-signed, or mismatched certificate.
Where wildcard certificates fall short in real environments
The main limitation is that wildcard coverage is narrower than many teams assume. It typically applies to one label beneath the registered domain, so *.example.org can cover api.example.org or portal.example.org, but not secure.api.example.org or the apex example.org itself. That means a healthcare organisation can believe it has broad protection while still leaving important names unprotected.
Wildcards also concentrate risk. If the private key is exposed, every covered subdomain inherits that exposure. That is why certificate handling should be treated as part of identity and key governance, not just web operations. NIST’s key-management guidance on cryptoperiods, protection, and lifecycle control is directly relevant here, especially when the same key can authenticate many endpoints at once. The NIST SP 800-57 Key Management guidance is a strong external reference for that control perspective.
Where teams use mutual TLS or service-to-service authentication, wildcard certificates can also blur ownership. A single certificate may terminate in multiple places, but that does not mean every service should share the same trust relationship. For workload identity design and trust-bundle thinking, NHIMG’s Guide to SPIFFE and SPIRE helps frame why shared certificates are not the same as shared identity.
What full certificate coverage should guarantee
Full coverage means deliberate name-by-name assurance. The objective is to ensure that all public-facing domains and subdomains are covered by an appropriate certificate, with no gaps between what users can resolve and what the certificate authorises. That usually includes the naked domain, any first-level subdomains, deeper subdomains where they exist, and any separate hostname used by a portal, API, vendor connection, or edge service.
For healthcare, that matters because the number of externally visible names often grows faster than certificate governance. Mergers, third-party hosted applications, patient-facing microsites, and temporary rollout hostnames all create opportunities for drift. Full coverage is therefore less about choosing a bigger certificate and more about maintaining an authoritative inventory and renewal process. NHIMG’s Ultimate Guide to NHIs, What are Non-Human Identities is relevant where those certificates are part of broader machine identity governance.
Full coverage also supports cleaner security operations. When each hostname has an explicit certificate decision, teams can spot expired assets, shadow endpoints, and inconsistencies sooner. In contrast, wildcard reliance can hide gaps until a browser warning, API failure, or integration error exposes the problem. If the goal is reliable encryption and authentication across a public estate, full coverage is the safer operating model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Certificate coverage depends on private-key lifecycle and cryptoperiod control. |
| Recommendation — Manage certificate keys with defined rotation, storage, and destruction requirements. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates are authenticators whose issuance, rotation, and revocation affect coverage. |
| Recommendation — Control certificate lifecycle, rotation, and revocation as managed authenticators. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Certificate protection and deployment are part of cryptographic control governance. |
| Recommendation — Define and enforce cryptographic controls for certificate use and protection. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Encrypted public services require consistent certificate coverage across exposed endpoints. |
| Recommendation — Maintain approved cryptographic protections for all public-facing services. | ||
Practitioner Guidance
What to verify: Build a complete inventory of every public healthcare hostname, then verify whether each one is covered by the intended certificate chain. Pay special attention to the apex domain, deeper subdomains, and temporary or third-party names that do not fit a wildcard pattern.
Decision rule: Use a wildcard only when the covered names are intentionally limited to one level and the shared key risk is acceptable. Treat full coverage as the default when certificate failure on any public hostname would create patient-facing, clinical, or integration downtime.
Common mistake: Teams often assume a wildcard plus a few service renewals equals comprehensive coverage. In practice, the gap usually appears in overlooked names, not in the main portal or primary API.
Practitioner takeaway: Wildcards reduce administration, but full coverage is what prevents silent certificate gaps. In healthcare, the right question is not which option is simpler, but which one gives you provable coverage for every name that matters.
Related resources from NHI Mgmt Group
- What is the difference between hybrid certificates and full quantum-safe migration?
- What is the difference between automating certificate issuance with ACME and managing certificates manually?
- How do organisations decide between wildcard certificates and individual certificates for subdomains?
- What is the difference between wildcard and multi-domain SSL certificates?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
