What should teams do first when they need custom SANs in certificate requests?

Start by defining certificate content guidelines that specify which identity fields belong in the original CSR and which requests require manual approval. Then require all custom SAN requests to be reviewed before signing, and avoid CA-wide settings that let request attributes override certificate identity. That sequencing preserves workflow flexibility without turning the CA into an impersonation enabler.

Define the CSR content before allowing custom SANs

The first decision is what belongs in the certificate request itself and what must be handled as an exception. Teams should set a content policy that names the allowed identity fields, the acceptable SAN patterns, and the cases that require manual approval before issuance.

That boundary matters because SANs can expand the identity asserted by a certificate far beyond the original subject. If requesters can add arbitrary names or attributes, the CA stops being a controlled issuer and starts becoming a tool for impersonation, especially in environments that rely on certificates for service, workload, or API authentication.

The practical test is whether the requested SAN is part of the intended identity or a separate assertion that needs human review. In public certificate ecosystems, issuance rules are tightly constrained by the CA/Browser Forum, which is a useful model for disciplined certificate content decisions even when you are operating your own CA.

Review custom SAN requests before signing

Custom SANs should be treated as an approval gate, not a self-service convenience. The review step is where teams confirm that the requested names match the asset, application, or environment the certificate will represent, and that the request does not silently widen trust to unrelated systems.

This is especially important when certificates are being used for machine or workload authentication. A SAN that looks harmless in a request form can become a privileged trust anchor once it is signed, so the signer needs enough context to catch mismatched hostnames, unauthorized aliases, and cross-environment identity leakage.

For teams that want a concrete lifecycle reference, Machine Identity, PKI and Certificate Lifecycle Guide covers why certificate lifecycle controls and renewal discipline must stay tied to identity governance rather than ad hoc issuance.

Avoid CA-wide overrides that let request attributes replace certificate identity

The main configuration mistake is to trust request attributes more than the certificate policy. If a CA is allowed to copy or override identity data from the request without restriction, a single malformed or malicious CSR can mint a certificate that asserts a different identity than the one the issuer intended.

That risk is not theoretical. Certificate-based systems are often consumed by clients that trust the signed subject and SANs more than the surrounding workflow, so weak CA settings can create durable trust errors that are hard to unwind after issuance.

When certificate trust is part of broader machine-to-machine authentication, Guide to SPIFFE and SPIRE is a useful companion because it shows how workload identity should stay anchored to explicit trust and attestation rather than loose certificate customization.

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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Certificate SAN control affects credential issuance and identity assertions.
	IA-9 — Service Identification and Authentication	Custom SANs commonly define service or workload identity in certificate-based auth.
	AC-6 — Least Privilege	Overbroad SAN overrides can grant more trust than a request should carry.
Recommendation — Constrain certificate issuance with policy-controlled authenticator handling and review. Bind service certificates to approved identity attributes before signing. Limit certificate issuance authority to the minimum identity attributes needed.
ISO/IEC 27001:2022	A.5.16 — Identity management	Custom SAN governance is an identity-management decision over certificate subjects.
Recommendation — Define approved certificate identity fields and review exceptions before issuance.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Unsigned or overbroad SANs can overstate non-human identity authority.
	NHI-04 — Insecure Authentication	Improper SAN handling can weaken certificate-based authentication trust.
Recommendation — Review SAN changes that expand non-human identity scope before signing. Ensure certificate identity claims are validated before a CA signs them.

Practitioner Guidance

What to verify: Confirm that the CA policy, enrollment workflow, and signer logic all agree on which fields are authoritative. The approval path should be able to block a certificate even when the CSR is technically valid.

Common mistake: Treating custom SAN support as a harmless convenience feature. In practice, this is an identity-expansion control, so the review standard should be as strict as any other privilege grant.

Practitioner takeaway: If a SAN can change what the certificate is trusted to represent, it belongs under explicit policy and approval before signing, not under requester-controlled override behavior.