Apply the same identity checks, approval discipline, and entitlement scoping that you would use for privileged access. If a request can create integrations, service accounts, or other non-human access, it should be governed as part of the broader identity lifecycle, not treated as a separate ITSM convenience.
Why app requests that spawn access should be treated as identity work
When an application request can create a service account, integration, API credential, or other non-human access path, the request is no longer just a convenience workflow. It is an identity lifecycle event with a security outcome. That means the request needs ownership, approval, scoping, and eventual removal rules that match the privilege being created, not the simplicity of the ticket.
The practical distinction is whether the request merely enables an app feature or actually creates standing access that can authenticate and act. If the latter is true, the approval should answer who owns it, what it can reach, how long it should exist, and what evidence will prove it was granted for a defined purpose.
Teams often get this wrong by letting ITSM process decide the control model. That usually produces orphaned access, unclear accountability, and a weak link between the original business request and the resulting entitlement. IAM and IGA Basics is useful here because the same access logic that governs human entitlements also governs machine and application access when the request creates a real authority boundary.
For teams handling service accounts and integrations, the key question is not “did someone submit a request?” but “did we create an identity that can now do work on our behalf?” That distinction matters because non-human access tends to outlive the ticket that created it unless the lifecycle is explicitly managed from day one. Service Account Security Guide and NHI Ownership and Accountability Guide both reinforce the need to assign ownership at creation, not after a problem appears.
What good approval discipline looks like for non-human access requests
Good discipline means the request is reviewed like privileged access, even if the requester frames it as an operational setup task. The approver should see the target system, the exact permissions, the business justification, the owner, the expiry or review point, and the recovery path if the access must be revoked quickly.
Entitlement scoping should be explicit and narrow. If the request says “integration user,” that is not enough. Teams should define whether the access is read-only or write-capable, whether it is environment-bound, whether it can call administrative functions, and whether it is allowed to reuse credentials across systems or environments. Human vs Non-Human Identity is a good reminder that these controls often fail at the handoff point between people and machine access, especially where shared credentials or delegated access are involved.
Lifecycle discipline should include offboarding and rotation, not just provisioning. If the request creates long-lived access, the team should have a named review cadence and a clear trigger for revocation when the business need ends. Guide to NHI Rotation Challenges is directly relevant when the access material cannot safely be left in place indefinitely.
How to operationalise this inside request, access, and platform workflows
The most effective pattern is to make identity controls part of the request template, not a downstream exception review. Request forms should force the requester to specify the system, purpose, owner, environment, required permissions, credential type, expiry expectation, and whether the request creates a reusable credential or a federated trust path.
Platform teams should also separate request approval from credential issuance. Approval says the access is allowed; issuance should create the credential, secret, token, certificate, or workload identity under controlled conditions, with logging and a revocation path. That separation reduces the chance that a ticket closure becomes the only evidence of control.
Where app requests routinely create non-human access, teams should align the process with broader identity governance rather than leave it in general service management. IAM and IGA Basics provides the governance lens, while NHI Governance Maturity Model helps teams see whether they have inventory, ownership, access review, and lifecycle controls around these identities.
Risk and Threat Considerations
When application requests create non-human access, the main risk is that a normal workflow becomes a durable privilege path. If the resulting identity is over-scoped, unowned, or never revisited, it can be abused for persistence, lateral movement, or unauthorized access long after the original request looks complete.
Failure mechanism: The request creates a credential or trust relationship that is not tied to a clear owner, expiry, or entitlement boundary, so the access survives beyond the business need and becomes difficult to detect or remove.
Impact: Attackers or careless operators can reuse that access to reach data or systems at machine speed, and defenders may struggle to distinguish legitimate automation from abuse because the access was never governed as a first-class identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Non-human access requests often create and lifecycle-manage credentials. |
| IA-9 — Service Identification and Authentication | Service accounts and integrations authenticate as non-human actors. | |
| AC-6 — Least Privilege | App-created access should be constrained to the minimum needed permissions. | |
| Recommendation — Set issuance, rotation, storage, and revocation rules for credentials created by app requests. Require strong authentication and scoped trust for service and integration identities. Restrict non-human entitlements to the minimum permissions the request requires. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The request changes who or what can access systems and data. |
| A.8.5 — Secure authentication | The request may create credentials or tokens used for machine authentication. | |
| Recommendation — Apply formal access control rules to app-created non-human access. Use secure authentication methods for any non-human access created by the request. | ||
Practitioner Guidance
What to verify: Before approving the request, confirm that the requester can name the owner, the exact systems in scope, the minimum permission set, and the planned review or expiry point. If any of those are missing, treat the request as incomplete rather than administrative overhead.
Decision rule: If the request creates anything that can authenticate or act independently, route it through identity and entitlement controls, not a generic task queue. If it only configures an app feature without creating standing access, a lighter process may be acceptable.
What good looks like: The approved access is traceable back to a business purpose, bound to a named owner, limited to the smallest useful scope, and removable without detective work when the integration is retired or changed.
Practitioner takeaway: The control objective is not to slow app requests down, but to prevent them from silently manufacturing standing privilege that nobody owns after the ticket closes.