Approved platforms can still host risky identities because the app, not the platform, defines who can act, what data can be reached and how long access persists. Service accounts, API tokens and agent identities often bypass normal lifecycle controls, especially when business users create them informally. That creates an identity governance gap even when the underlying platform is sanctioned.
Approved platforms still create identity risk when the app owns the access model
Business-built apps often sit on top of sanctioned SaaS, cloud or automation platforms, but the platform boundary does not define the real trust boundary. The app decides which users, services and agents exist, which data they can touch, and whether access is short-lived, reviewable or effectively permanent. That is why the risk is usually in the app’s identity design, not the platform label.
In practice, low-code tools, workflow builders and internal apps make it easy to create accounts, grant token-based access and connect to APIs without routing those decisions through the platform’s normal governance path. That creates shadow lifecycle management: identities are born, copied, shared or abandoned inside an approved environment, but they never enter the same review, ownership and revocation process as centrally managed accounts.
That separation matters because identity risk is not only about where the software runs. It is about whether every actor has a clear owner, a valid purpose, bounded privileges and a reliable offboarding trigger. When the app is the place where permissions are assigned and secrets are issued, the organisation can end up with approved infrastructure and unmanaged authority at the same time.
Why informal service accounts, API tokens and agent identities are the pressure points
Business-built apps commonly rely on non-human identities because they are easier to automate than human logins. Service accounts, API tokens, signed assertions and agent credentials often survive longer than the business process they were meant to support. If the app creator can mint them without the same controls used for workforce access, those identities can accumulate privilege, persist after the business need ends and remain invisible to access review.
This is where the governance gap becomes operational. The platform may support logging or secret storage, but it does not automatically enforce identity lifecycle discipline for every app-created credential. The risk grows when users bypass standard onboarding by reusing personal access, embedding secrets in workflows or sharing a single technical identity across multiple processes. Those patterns break attribution, make least privilege hard to verify and complicate incident response when something behaves unexpectedly.
For teams trying to reduce that exposure, the useful question is not whether the platform is approved. It is whether the app can create identities that outlive their purpose, exceed the intended scope, or escape revocation when ownership changes. NHIMG’s NHI Lifecycle Management Guide is relevant here because the failure mode is fundamentally about provisioning, rotation, offboarding and visibility, even when the underlying platform is sanctioned.
What makes sanctioned platforms attractive to identity sprawl
Approved platforms often give business teams enough freedom to move fast, which is useful until that freedom becomes a parallel identity plane. The most common pattern is decentralised creation with centralised trust: the platform is trusted, so the identities created inside it are trusted by default. That assumption is dangerous because the app can create broad access paths long before security teams can confirm ownership, necessity or expiry.
The result is identity sprawl with a clean compliance wrapper. Credentials and service principals appear legitimate because they were created inside an approved platform, yet they may have excessive scope, weak separation between environments, or no durable record of who approved them. The issue is amplified when workflows are cloned, tested and promoted without resetting embedded identities, because the same token or account can end up reused across sandboxes, staging and production.
Business teams also tend to optimise for continuity, not revocation. If a process breaks when a token expires, they may extend it rather than redesign it. That creates long-lived access paths that are difficult to inventory and harder to challenge later. The platform is still approved, but the app has quietly turned convenience into standing privilege.
Risk and Threat Considerations
Approved platforms can become high-risk identity factories when business users are allowed to create access paths faster than governance can see them. The main exposure is not platform compromise, but unmanaged authority: overprivileged or orphaned technical identities can be used for unauthorised data access, lateral movement or persistent access after the business owner has moved on.
Failure mechanism: App-created identities bypass standard lifecycle controls, so rotation, review and revocation do not happen at the same pace as platform deployment. When a token, service account or agent credential is copied, shared or left in place after a workflow changes, the organisation loses control over who can act and for how long.
Impact: The business can retain a sanctioned platform while inheriting hidden access paths, excessive privilege and weak accountability. That increases the chance of unauthorised access, difficult-to-trace activity and delayed containment when an identity is abused or forgotten.
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 and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | App-created tokens and secrets need lifecycle control, rotation and revocation. |
| AC-6 — Least Privilege | Business-built apps can overgrant access through service accounts and tokens. | |
| IA-9 — Service Identification and Authentication | The issue centers on non-human identities authenticating to systems and APIs. | |
| Recommendation — Enforce IA-5 to rotate, track and revoke app-issued credentials on a defined schedule. Apply AC-6 to limit each app identity to the minimum permissions it needs. Use IA-9 to authenticate services and workloads with controlled, auditable identities. | ||
| CIS Controls v8 | 5 — Account Management | The risk is unmanaged creation and retention of app-specific identities. |
| Recommendation — Implement CIS-5 to inventory, review and remove application accounts and tokens promptly. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | App identities often persist after the business process ends. |
| NHI-05 — Overprivileged NHI | Business-created identities can accumulate excess access inside approved platforms. | |
| NHI-07 — Long-Lived Secrets | The question highlights tokens and credentials that outlast their intended use. | |
| Recommendation — Address NHI-01 by revoking app identities when the workflow or owner changes. Apply NHI-05 to reduce permissions on service accounts and agent credentials. Mitigate NHI-07 by shortening token lifetime and replacing durable secrets with rotated credentials. | ||
Practitioner Guidance
What to prioritise: Treat app-created identities as governed assets, not implementation details. The first control question is whether every non-human identity has an owner, a purpose and an expiry or review trigger that is independent of the app release cycle.
What to verify: Check whether the platform can inventory service accounts, API tokens and agent identities separately from human users, and whether those identities are recertified, rotated and removed when a workflow is retired. If you cannot prove those controls with evidence, assume the app has created an unmanaged identity layer.
Common mistake: Teams often approve the platform and then assume the app inherits the platform’s governance. In reality, the app may be the system of record for access decisions, which means security review has to focus on the identities the app creates and the secrets it exposes, not only on the platform’s baseline controls.
Practitioner takeaway: The key test is whether access can be created, extended and forgotten inside the app faster than the organisation can observe and revoke it. If yes, the platform is approved, but the identity model is not under control.
Related resources from NHI Mgmt Group
- Why do non-human identities create compliance risk even when policies exist?
- Why do shadow apps create identity risk even when inventory tools are in place?
- Why do unmanaged SaaS apps create identity risk even when users sign in legitimately?
- Why do shadow IT apps create identity risk even when users still have valid SSO access?