Supply in Request is a certificate template setting that allows the requester to provide subject information during enrollment. In AD CS, this can be dangerous if combined with weak access controls or misconfigured issuance rules, because it may let an attacker shape a certificate for unauthorized authentication purposes.
Expanded Definition
Supply in Request is a certificate template setting in Microsoft AD CS that permits the requester to enter subject details during enrollment rather than relying only on directory-populated attributes. That flexibility can be useful for edge cases, but it also shifts trust to the enrollment path and the issuing policy that evaluates the request.
In NHI security terms, the setting matters because certificate subject content can influence how a certificate is later interpreted for authentication, mapping, or delegation. When combined with weak enrollment permissions, permissive issuance requirements, or poorly constrained template duplication, it can create a path for certificate abuse that looks legitimate at the point of issuance but is not legitimate in identity assurance terms. This is why practitioners should treat it as an identity-control decision, not just a convenience feature. For broader identity governance context, NHI Mgmt Group’s Ultimate Guide to NHIs is a useful reference on lifecycle and privilege risk, while NIST Cybersecurity Framework 2.0 provides a governance lens for access control and protection.
The most common misapplication is enabling supply-in-request on templates that can be enrolled by broad groups, which occurs when administrators assume the template boundary is sufficient even though the requester can shape identity fields used downstream.
Examples and Use Cases
Implementing Supply in Request rigorously often introduces enrollment friction, requiring organisations to weigh certificate issuance flexibility against stronger validation and review steps.
- A PKI team allows supply-in-request for a lab-only template so testers can enroll certificates with nonproduction subject values without modifying directory records.
- An internal application uses a constrained template where the requester supplies only a limited subject attribute set, while issuance rules and approval workflows still enforce identity validation.
- A red-team exercise demonstrates how a misconfigured template can be abused when subject supply is paired with overly permissive enrollment rights and weak manager approval. NHI Mgmt Group’s Ultimate Guide to NHIs helps frame why such misconfigurations quickly become privilege issues.
- A security architect documents a certificate request workflow against the NIST Cybersecurity Framework 2.0 to align issuance controls with least privilege and validation requirements.
- A migration team disables subject supply on templates used for machine authentication to reduce the chance that requesters can influence identity binding during automated enrollment.
Why It Matters in NHI Security
Supply in Request becomes dangerous when the certificate itself is treated as proof of identity without enough scrutiny over who requested it, what subject fields were supplied, and whether the issuing policy actually enforced those fields. In NHI environments, that can turn certificate enrollment into an identity forgery path rather than a controlled onboarding step. This is especially relevant for service accounts, automation identities, and any workflow where certificates are used as durable authentication material.
NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, and certificate mis-issuance sits in the same family of credential governance failures: once trust material is exposed or shaped incorrectly, recovery is often slow and incomplete. The control objective is not to ban flexibility everywhere, but to ensure that requester-supplied subject data cannot override identity assurance, approval logic, or constrained issuance policy. Practitioners also use NIST Cybersecurity Framework 2.0 to map certificate issuance into protection and access governance.
Organisations typically encounter the consequence only after a suspicious certificate is discovered in authentication logs, at which point Supply in Request 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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Covers risky NHI issuance paths and misconfigured trust that can enable credential abuse. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is central to preventing broad enrollment abuse. |
| NIST Zero Trust (SP 800-207) | PA-3 | Zero Trust requires strong identity binding before a certificate is accepted as trustworthy. |
| NIST SP 800-63 | IAL2 | Identity proofing strength influences whether requester-supplied subject data is acceptable. |
| CSA MAESTRO | Agentic and machine identities need constrained issuance and strong trust boundaries. |
Restrict certificate templates and validate request inputs so enrollment cannot shape unauthorized identity trust.
Related resources from NHI Mgmt Group
- Why do fork based pull request workflows increase supply chain risk in cloud native development?
- What is supply chain amplification in Agentic AI security?
- How do attackers turn a supply-chain incident into wider NHI compromise?
- When should organisations rotate credentials after a supply chain incident?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
