What is the difference between per certificate licensing and SAN based licensing for SSL and TLS management?

Why Licensing Model Choice Changes Certificate Operations

Per certificate and SAN based licensing sound similar, but they push teams toward different operational behaviours. Per certificate models treat each issuance as a cost event, so frequent rotation, short validity periods, and multiple environment-specific certificates can create procurement pressure. SAN based licensing shifts the unit of charge to the active name set, which usually fits estates that reuse the same subject alternative names across renewals and reissues. For security teams, the practical question is not just pricing but whether the model supports the certificate lifecycle the organisation actually needs. In practice, many security teams discover the licensing mismatch only after renewal automation or certificate rotation has already been standardised.

For readers comparing control implications, NIST Cybersecurity Framework 2.0 is useful because certificate licensing decisions often sit inside broader asset, governance, and recovery decisions rather than in a narrow PKI silo.

How Per Certificate and SAN Based Licensing Behave in Practice

Per certificate licensing is straightforward when the operational model is stable and issuance volume is low. Each certificate counted against the licence can make cost forecasting simple, but it can also discourage good hygiene if teams begin extending certificate lifetimes just to avoid reissuance costs. That creates a subtle tradeoff: the licence is easier to understand, yet the organisation may drift toward slower rotation or more manual approval gates.

SAN based licensing works differently because the focus is on the number of active unique names rather than the number of certificates issued over time. That usually aligns better with environments that automate renewal, split traffic across multiple endpoints, or reissue certificates often for resilience or change management reasons. It can also make inventory discipline more important, because duplicated or stale SANs can consume capacity without adding value.

• Per certificate models fit low-churn environments where issuance is infrequent and predictable.
• SAN based models fit estates where the same identities are reissued often, but the active name set stays relatively stable.
• Short-lived certificates are easier to justify under SAN based licensing when licence count tracks active names rather than issuance events.
• Operationally, the decisive issue is whether the vendor counts issued objects or counted names at a point in time.

Teams should read the licence definition carefully, because some products count wildcards, duplicates, staging names, or retired SANs differently. The point of control is not the label on the certificate but the exact counting rule used for billing and enforcement. Where the commercial model is ambiguous, certificate automation tends to expose the ambiguity quickly, and that is where the guidance starts to break down.

When the Licensing Model Becomes a Governance Problem

Tighter certificate governance often increases administrative overhead, requiring organisations to balance renewal discipline against licensing constraints. That tradeoff matters most when certificate management is tied to multiple teams, external issuers, or fast-moving application estates.

One common edge case is renewal automation: a per certificate model can make automation look expensive because each renewal appears as a fresh charge, while a SAN based model may make the same automation economically viable if the active SAN set remains unchanged. Another edge case is certificate sprawl across test, pre-production, and production environments. If non-production names are counted the same way as production names, the SAN model can still create friction, but the friction shifts from issuance volume to naming discipline.

There is also a governance distinction between price predictability and identity hygiene. SAN based licensing can make rotation easier, but it does not remove the need to control unused names, validate ownership, or retire stale entries. Per certificate licensing can be simpler for small estates, yet it can also create a hidden incentive to retain certificates longer than operationally ideal. NIST Cybersecurity Framework 2.0 is the better fit when the organisation wants to treat certificate lifecycle cost as part of broader resilience and governance planning, not just as a procurement detail.

Practitioner Guidance

What to verify: Confirm exactly what the vendor counts. The practical decision hinges on whether the licence is triggered by each issuance, each active SAN, or some hybrid rule that treats renewals, duplicates, and staging names differently.

Decision rule: If your organisation rotates certificates frequently, prefer the model that charges for active unique SANs unless the contract explicitly makes reissue volume irrelevant. If your estate is small and stable, per certificate pricing may be acceptable if it does not discourage timely renewal.

What practitioners underestimate: The commercial model can shape security behaviour. A poorly matched licence sometimes causes teams to defer rotation, compress change windows, or hide certificate sprawl in ways that are operationally convenient but weak from a hygiene perspective.

Practitioner takeaway: Choose the licensing model that fits your certificate lifecycle, not the one that merely looks cheaper in a static spreadsheet, because the wrong counting rule can quietly distort renewal and rotation decisions.

Related resources from NHI Mgmt Group

• What is the difference between certificate management and NHI governance?
• What is the difference between certificate management and machine identity management?
• What is the difference between certificate management and certificate lifecycle management?
• What is the difference between certificate-based authentication and FIDO in practice?