Wildcard Certificates: The Operational Shortcut That Becomes a Strategic Liability

Part of the Machine Identity Management guide.

The Appeal Is Obvious

A wildcard certificate covers every subdomain under a given domain with a single certificate. One purchase, one renewal, one deployment — and *.yourcompany.com protects everything from your API to your marketing site to that internal tool someone spun up last month.

For organisations managing dozens or hundreds of subdomains, the arithmetic looks compelling. Fewer certificates means fewer renewals, fewer procurement cycles, and fewer things to track. Finance likes the consolidated line item. Operations likes the simplicity.

What nobody accounts for at purchase time is the operational debt that accumulates as the organisation grows around that wildcard.

What Wildcard Certificates Actually Cost

The Visible Costs

A wildcard certificate from a commercial CA typically costs 3–10x more than a single-domain certificate. At face value, it breaks even once you have more than a handful of subdomains. For organisations with 20, 50, or 100+ subdomains, the per-domain cost looks like a bargain.

This is the number that appears in the budget. It's also the least important number in the equation.

The Hidden Operational Costs

Key distribution overhead. Every service that uses the wildcard needs a copy of the same private key. That key must be securely distributed to every server, container, and load balancer across every environment — production, staging, development, disaster recovery. Each copy is a potential exposure point, and each distribution event is an operational step that must be tracked, secured, and audited.

In a mid-size deployment, a single wildcard certificate's private key might exist in 30–50 locations. Managing the secure distribution and rotation of that key across all of those locations is significantly more operational work than it appears on paper.

Blast radius during incidents. When a wildcard certificate needs to be revoked — because a key was compromised, a server was breached, or a compliance event requires it — every service sharing that certificate is affected simultaneously. This isn't a localised incident. It's a coordinated, organisation-wide re-provisioning exercise that touches every team running services under that domain.

The incident response cost scales with the number of services, the number of teams involved, and the speed at which re-provisioning must happen. For organisations without automated certificate lifecycle management, this can mean hours to days of disruption.

Renewal coordination. A wildcard certificate has a single expiry date. When it renews, the new certificate and key must be deployed to every location simultaneously. Miss one server, and that service breaks. In organisations where different teams own different subdomains, renewal becomes a cross-team coordination exercise — typically managed through spreadsheets, calendar reminders, and hope.

Compliance and audit friction. Regulatory frameworks increasingly expect segmented, auditable certificate management. When an auditor asks “which systems have access to the private key that protects your payment processing subdomain?” and the answer is “every system under our domain, including the company blog and the intern's test environment,” the conversation becomes expensive.

PCI DSS, SOC 2, ISO 27001, and sector-specific regulations all create pressure toward demonstrating that cryptographic material is scoped appropriately. Wildcards are the opposite of scoped. For regulated environments, see also regulated PKI implementation patterns.

The Scenarios Where Wildcards Create Business Risk

Subdomain Takeover

When your organisation decommissions a service but doesn't clean up the DNS record, that dangling subdomain becomes a target. An attacker who claims the abandoned subdomain gets a valid identity for free — the wildcard already covers it. No new certificate needed. No CA interaction. Just a DNS record pointing at attacker-controlled infrastructure, already trusted by your wildcard.

This isn't a theoretical scenario. Subdomain takeover via dangling DNS is one of the most commonly exploited vulnerabilities in enterprise environments, and wildcard certificates make it significantly easier to weaponise.

Shadow IT Expansion

Wildcards cover subdomains that don't exist yet. Every new subdomain created by any team, for any purpose, automatically receives TLS coverage without any review or approval. This removes a natural governance checkpoint — the moment when someone has to request a certificate and justify the service's existence.

For organisations trying to maintain visibility into their infrastructure, wildcards create a blind spot. Services appear and disappear under the wildcard umbrella without any certificate-level audit trail.

Vendor and Partner Exposure

If your wildcard certificate's private key is shared with a managed service provider, a CDN vendor, or a hosting partner, the compromise of their systems exposes every subdomain under your domain. The security boundary of your wildcard is defined by the weakest security posture among every entity that holds a copy of the key.

CA Lock-In

A wildcard certificate ties all covered subdomains to a single certificate authority. If that CA experiences an incident, changes pricing, or is distrusted by browsers (as has happened with major CAs in the past), migrating is an all-or-nothing exercise. You can't gradually move subdomains to a different CA — the wildcard is a single certificate from a single issuer.

With individual or SAN certificates, CA migration is incremental. You can move services one at a time, test, validate, and roll back if needed.

When Wildcards Are the Right Choice

Wildcards aren't inherently wrong. They're a tool with a specific set of appropriate use cases:

Uniform infrastructure under single-team ownership. A CDN edge fleet, a cluster of identically configured application servers, or a set of regional endpoints all managed by one team with consistent security controls. The key distribution problem is contained because the infrastructure is homogeneous.

Short-lived ephemeral environments. CI/CD pipelines, development sandboxes, or test environments that exist for hours or days. The exposure window is small enough that the shared-key risk is manageable, and the environments are destroyed before operational debt accumulates.

Internal environments with private CAs. When the certificate never touches the public internet and you control the entire trust chain, several of the public-trust risks disappear. You still have the shared-key problem, but you can offset it with aggressive rotation and short certificate lifetimes.

Early-stage organisations with minimal infrastructure. If you have five subdomains, one environment, and one person managing everything, a wildcard is a reasonable starting point. The key is recognising when you've outgrown it — which typically happens earlier than expected.

The Alternative: Automated Per-Service Certificates

The reason wildcards became standard practice was that provisioning individual certificates was manual, slow, and expensive. A wildcard was the rational response to a broken process.

That process has changed. ACME-based automation can provision, deploy, and renew individual certificates for any number of subdomains without human intervention. The operational cost of managing 500 individual certificates through automation is lower than managing one wildcard manually — because the automation handles the renewal coordination, deployment, and tracking that wildcards push onto your teams.

Per-service certificates also deliver benefits that wildcards structurally cannot provide:

Isolation. A compromised certificate affects one service. Revocation affects one service. The blast radius of any incident is contained to the service involved.

Auditability. Every certificate maps to a specific service, owner, and purpose. Certificate inventories become meaningful. Compliance conversations become straightforward.

CA flexibility. Different services can use different CAs. You can negotiate better rates, maintain redundancy, and migrate incrementally.

Governance. Certificate issuance becomes a control point. New services require a certificate, which requires a request, which creates a record. Shadow IT becomes visible.

The Migration Decision

Moving away from wildcards isn't a weekend project, but it doesn't need to be a multi-quarter initiative either. The typical path:

Phase 1 — Visibility. Audit where your wildcard private keys actually live. Most organisations discover copies in locations they didn't expect. This step alone often provides the business justification for the migration.

Phase 2 — Automation. Deploy certificate lifecycle automation. This is the prerequisite. Replacing wildcards with manually-managed individual certificates makes the operational problem worse, not better.

Phase 3 — Incremental migration. Move services off the wildcard one at a time, starting with the highest-risk subdomains (those handling sensitive data, customer-facing services, regulated workloads). Each migration reduces the wildcard's blast radius.

Phase 4 — Scoped retention. Keep wildcards only for the use cases where they're genuinely appropriate — the CDN fleet, the ephemeral environments, the homogeneous infrastructure under single-team control.

The Business Case in One Paragraph

Wildcard certificates trade upfront simplicity for compounding operational risk. As your organisation grows, the shared-key distribution problem, the coordination overhead of renewal and revocation, the compliance friction, and the blast radius of any incident all scale with the number of services under the wildcard. Automated per-service certificates eliminate these scaling problems while costing less in operational overhead than wildcard distribution. The question isn't whether you'll eventually need to move away from wildcards. It's whether you do it proactively or in response to an incident.

Most organisations we work with are running wildcards across environments with very different security requirements. If you're unsure about your exposure, start with a certificate landscape assessment.