A service request that alters an account, entitlement, credential, or permission set rather than simply restoring or reporting service. These requests need stronger governance because they directly affect access state and can create audit, compliance, and security risk.
Expanded Definition
An identity-changing Request is not a routine support ticket. It is any approved or proposed action that changes who or what can authenticate, what the identity can access, or how long that access remains valid. In NHI operations, that includes service-account role changes, API key replacement, certificate renewal, token scope expansion, and ownership transfers for privileged automation.
Definitions vary across vendors, but the governance expectation is consistent: a change request that alters identity state should be treated as a control point, not an administrative convenience. That makes it different from incident restoration, password reset, or service restoration, because the request can create new authorization paths and new audit obligations. This is closely related to least privilege and change control concepts in the NIST Cybersecurity Framework 2.0, but NHI programs often need stricter handling because machine identities can be copied, embedded, and reused at scale.
NHIMG guidance on the Ultimate Guide to NHIs emphasizes that identity state must be visible across the lifecycle, not only at issuance. The most common misapplication is treating an identity-changing Request like a standard service request, which occurs when approvers do not verify the access impact before the change is executed.
Examples and Use Cases
Implementing identity-changing Request controls rigorously often introduces approval latency, requiring organisations to weigh faster delivery against stronger access assurance.
- A DevOps team requests a scope increase for a deployment token so a CI/CD pipeline can reach a production registry. The change is valid only if the ticket records the exact new scope, expiry, and rollback plan.
- A security engineer rotates a service-account certificate after a detected exposure. The request should capture replacement timing, dependent systems, and whether the old credential is revoked immediately.
- An application owner asks to transfer ownership of an API key from one automation job to another. This should trigger revalidation of accountability, logging, and downstream trust relationships.
- A platform team temporarily grants elevated permissions for maintenance. The request should specify a time bound and removal step, not just the expanded role.
- After a suspected compromise, a revocation-and-reissue workflow is opened for a bot identity. The NHIMG 52 NHI Breaches Analysis shows why identity state changes often become urgent during response, not just during planning.
For service-account and token handling, teams may also align request evidence with guidance from the NIST Cybersecurity Framework 2.0 so approvals include asset context, risk, and traceability.
Why It Matters in NHI Security
Identity-changing Requests matter because they are one of the easiest places for privilege drift, shadow admin paths, and poor audit evidence to enter an environment. When a request changes a credential, scope, or entitlement without strong review, the organisation may create an access state that no longer matches the intended control design. That is especially risky for NHIs, where a single change can cascade into multiple systems, CI/CD workflows, or third-party integrations.
NHIMG reports that 97% of NHIs carry excessive privileges, which makes every identity state change a potential amplifier of existing overreach rather than a neutral administrative step. The Top 10 NHI Issues further highlights how weak governance around lifecycle actions contributes to exposure and recovery friction. The same concern appears in the Ultimate Guide to NHIs, where visibility and rotation are presented as core controls, not optional maturity upgrades.
Practitioners should treat these requests as a governance checkpoint for access intent, evidence, and time limits. Organisations typically encounter the operational consequences only after an incident review, at which point the identity-changing Request becomes unavoidable to reconcile who changed what, when, and why.
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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Identity changes directly affect NHI lifecycle, privilege, and auditability. |
| NIST CSF 2.0 | PR.AC-4 | Access changes must preserve least privilege and traceable authorization. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust expects continuous verification when identity state or access paths change. |
Require documented approval, scope review, and rollback steps for every NHI state change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
