What is the difference between a SAN certificate and issuing separate certificates for each website?

A SAN certificate can cover multiple domains, subdomains, IP addresses, or other supported identifiers under one certificate, while separate certificates require one issuance per site. The SAN model reduces administrative overhead and can improve consistency across a multi site estate. Separate certificates may be simpler in small environments, but they scale poorly as sites multiply.

Why SAN Certificates and Per-Site Certificates Solve Different Operational Problems

The practical difference is not just technical packaging. A san certificate centralises trust for several names, which can simplify inventory, renewal, and consistency across related properties. Separate certificates decentralise that trust, which gives you narrower blast radius and more independent lifecycle control, but at the cost of more issuance, more renewal events, and more chances for drift. For teams running multiple sites, the real question is often whether they value operational simplicity more than isolation and granular control. In practice, many teams discover the trade-off only after renewal coordination or hostname sprawl has already become a maintenance problem.

For the security angle, the certificate model affects how mistakes propagate. If a SAN certificate is deployed incorrectly, the issue can affect every name on that certificate. If separate certificates are managed badly, the problem is usually not shared exposure but inconsistent hygiene across individual sites. NIST’s control guidance on maintaining system integrity and controlled configuration is a useful reference point here, especially when certificate handling is part of a broader asset or service governance process. NIST SP 800-53 Rev 5 Security and Privacy Controls

How SAN Certificates Change Deployment, Renewal, and Failure Modes

A SAN certificate binds one private key and one certificate object to multiple subject alternative names, so the deployment model is built around shared lifecycle management. That means one issuance, one renewal process, and one revocation event for the covered names. The upside is efficiency. The downside is concentration: if the certificate expires, is misissued, or the private key is exposed, every site on that certificate is affected at once. That is why SAN certificates are usually most attractive when the sites share administration, hosting, and change control.

Separate certificates break that coupling. Each website can be renewed, rotated, revoked, and replaced on its own schedule. That improves fault isolation and can be preferable when sites belong to different business units, have different hosting stacks, or require different trust boundaries. The trade-off is operational overhead. More certificates usually means more policy exceptions, more renewal tracking, and more opportunities for one site to be forgotten during a migration or hostname change.

Use a SAN certificate when the sites share ownership, controls, and operational cadence.
Use separate certificates when you need tighter isolation between properties or teams.
Check whether one hostname change could force emergency reissuance across multiple services.
Verify that your monitoring can see certificate expiry, revocation, and key changes for every covered name.

The guidance breaks down when the certificate estate spans unrelated brands, legal entities, or environments, because the shared-key model then turns convenience into unnecessary coupling.

Where SAN Certificates Stop Being the Better Default

Tighter consolidation often reduces admin work, but it also increases shared failure impact, so organisations need to balance efficiency against isolation. That is why the better choice depends on operational ownership, not just certificate count. If all sites are managed together and change at the same pace, a SAN certificate can be sensible. If the sites differ in risk profile, release cadence, or control ownership, separate certificates are usually easier to govern even if they are less efficient.

Edge cases matter. Wildcard certificates are not the same as SAN certificates, because they solve a different naming problem and can obscure how much of the estate is really covered. Mixed estates also create confusion: teams sometimes use SAN certificates for convenience at the edge while keeping separate certificates for internal or higher-risk services. That is a legitimate pattern when there is a clear boundary, but it only works if certificate inventory, renewal ownership, and revocation procedures are explicit. The better practice is to treat certificate design as part of service architecture, not as a one-time procurement choice. Where there is disagreement, the consensus favours narrower certificates for stronger isolation, but that is a governance judgement, not an absolute rule.

If the environment is large, the deciding factor is usually whether your teams can prove who owns renewal, revocation, and emergency replacement for every covered hostname.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-1 — Identity and Credential Management	Certificates are credentialing artefacts that require lifecycle control.
	PR.AC-4 — Access Permissions and Authorizations	Certificate scope affects which services can present trusted identities.
	GV.OC-3 — Legal and Regulatory Requirements	Certificate choice can reflect ownership, accountability, and service boundaries.
Recommendation — Apply PR.AC-1 to manage certificate issuance, renewal, and revocation consistently. Use PR.AC-4 to limit certificate scope to the services that actually need it. Map certificate ownership and coverage to the accountable service owner under GV.OC-3.
CIS Controls v8	6.3 — Address Unapproved Software and Services	Certificate sprawl often follows unmanaged website growth and shadow services.
	4.3 — Automated Backup of Data	Certificate replacement depends on reliable recovery of configuration and keys.
Recommendation — Use 6.3 to inventory services before consolidating them under shared certificates. Ensure certificate and key recovery procedures are backed up and testable under 4.3.
MITRE ATT&CK	T1552.004 — Private Keys	Shared certificates concentrate private-key exposure into one compromise point.
	T1485 — Data Destruction	Revocation or mismanagement can take multiple sites offline when trust is centralised.
Recommendation — Monitor for private-key exposure and rotate affected certificates immediately under T1552.004. Treat certificate compromise as a service-impacting event and prepare rapid replacement under T1485.

Practitioner Guidance

What to prioritise: Decide whether your main concern is operational consolidation or failure isolation. If the answer is consolidation, SAN may fit; if it is containment, separate certificates are usually the better fit.

What to verify: Confirm that certificate ownership, renewal dates, private-key handling, and hostname coverage are all tracked at the same granularity as the business services they support. A shared certificate should not hide separate operational responsibilities.

Common mistake: Treating SAN as a default scaling shortcut. It reduces certificate count, but it does not reduce the need for disciplined inventory, change control, and emergency replacement planning.

Practitioner takeaway: Choose the certificate model that matches your failure domain, because the cheapest approach administratively can become the most expensive one the moment a shared certificate fails.