Subject Alternative Name, or SAN, is a certificate field that can hold additional identities beyond the primary subject. If users can influence SAN values in unsafe ways, the certificate may authenticate as a different or more privileged identity than intended.
Expanded Definition
Subject Alternative Name, or SAN, is the certificate extension that lets one certificate assert multiple identities, such as a DNS name, IP address, URI, or email address. In NHI and machine identity practice, SAN is often the field that actually determines what an agent, service, or workload can authenticate as, which is why certificate issuance policy matters as much as key protection.
Definitions vary across vendors in how they describe SAN governance, but the security principle is consistent: the certificate should only contain identities that were explicitly approved for that workload. This aligns with the identity assurance and access governance expectations reflected in the NIST Cybersecurity Framework 2.0, especially where authenticated entities must be bound to authorised use. In practice, SAN becomes a control point for workload identity, mutual TLS, and automated trust decisions.
The most common misapplication is allowing application teams or pipelines to write arbitrary SAN values during certificate request or renewal, which occurs when approval logic is weak or enrollment services are overly permissive.
Examples and Use Cases
Implementing SAN rigorously often introduces certificate issuance friction, requiring organisations to weigh deployment speed against stronger identity binding and lower impersonation risk.
- A workload certificate includes only the service DNS name and a specific SPIFFE URI, preventing the same certificate from being reused by another workload.
- A CI/CD pipeline requests a certificate for an internal API, but the certificate authority validates the requested SAN against an approved service registry before issuing it.
- An mTLS gateway uses SAN matching to verify that a client certificate belongs to the intended service account rather than just trusting the issuer chain.
- An organisation reviewing machine identity sprawl finds that several certificates contain extra SAN entries, and the excess values expand the blast radius if the private key is stolen. The Ultimate Guide to NHIs shows why visibility and lifecycle control are central to reducing this exposure.
- A developer requests a certificate for testing and later reuses it in production, but certificate policy blocks the request because the SAN does not match the production identity profile defined by the CA.
For identity formats that rely on structured workload identifiers, NIST Cybersecurity Framework 2.0 supports the broader expectation that access decisions should be tied to verified identity attributes, not convenience-based issuance.
Why It Matters in NHI Security
SAN is important because it can quietly turn certificate metadata into an authentication decision. If SAN values are not tightly controlled, an attacker who can influence certificate requests may obtain a credential that authenticates as a more privileged service, gateway, or API endpoint than intended. That is a direct NHI governance failure, not just a PKI hygiene issue.
This matters especially in environments with high secret exposure. NHI Mgmt Group reports that Ultimate Guide to NHIs notes 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, which shows how quickly weak machine identity controls become operational incidents. A certificate with unsafe SAN values can defeat segmentation, misroute trust, and let one compromised workload impersonate another across service meshes, automation tools, and API gateways.
Governance teams should treat SAN review as part of certificate policy, issuance approval, and renewal validation. Certificates should be mapped to a known workload inventory, and any extra identity entry should be considered suspect until proven necessary. Organisations typically encounter SAN abuse only after a certificate is abused in lateral movement or unauthorized service impersonation, at which point SAN becomes operationally unavoidable to address.
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 SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | SAN misuse enables certificate identity abuse and weak secret governance. |
| NIST SP 800-63 | Applies assurance thinking to identity binding, though it does not define SAN directly. | |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and credential issuance controls support safe certificate identity assignment. |
Restrict certificate SAN issuance to approved workload identities and review for excess identity claims.
