A non-human identity used by an application or service to access platform resources. In Power Platform, the key issue is not whether the identity can authenticate, but whether platform governance controls constrain it the same way they constrain human users. Actor type determines enforcement.
Expanded Definition
An application user is a non-human identity that an application, workflow, or service uses to reach platform resources under a defined access pattern. In NHI governance, the crucial question is not only whether the identity can authenticate, but whether its permissions, lifecycle, and usage context are constrained with the same rigor applied to human accounts.
In Power Platform and similar environments, the term is often used to describe an identity that acts on behalf of a business process rather than an employee. That distinction matters because platform enforcement can change based on actor type, tenancy, connector scope, and whether the identity is treated as an interactive user, a service principal, or a managed application. Definitions vary across vendors, so practitioners should validate how the platform classifies the account before assuming standard IAM controls will apply. Guidance in the NIST Cybersecurity Framework 2.0 reinforces the need to govern identity access as an operational control, not just an authentication event, while NHIMG research shows why this matters at scale in the Ultimate Guide to NHIs.
The most common misapplication is treating an application user as a generic shared account, which occurs when platform owners grant broad access without separating workload identity from human administrative access.
Examples and Use Cases
Implementing application user governance rigorously often introduces operational friction, requiring organisations to balance automation convenience against tighter privilege boundaries and more deliberate change control.
- An internal finance app uses a dedicated application user to read records from Dataverse, with access limited to one environment and one table set.
- A Power Automate flow authenticates through an application user to post alerts into Teams, but the identity is restricted from direct data export and tenant-wide administration.
- A scheduled integration writes customer updates to a downstream API, and the application user is rotated and monitored separately from developer accounts.
- An analytics job runs under a workload identity that is exempt from interactive sign-in, yet still governed by conditional access, logging, and least-privilege review.
- NHIMG notes that 97% of NHIs carry excessive privileges in many environments, which makes an application user a prime candidate for scope reduction and access review in the Ultimate Guide to NHIs.
When platform semantics are unclear, teams should consult the platform’s identity model alongside external guidance such as the NIST Cybersecurity Framework 2.0 rather than assuming that service usage automatically implies service-account protections.
Why It Matters in NHI Security
Application users are high-value NHI assets because they often sit at the intersection of automation, data access, and privileged integration. If they are over-permissioned, reused across systems, or left outside normal governance workflows, they become persistent access paths that are difficult to detect and even harder to unwind after an incident. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 5.7% of organisations have full visibility into their service accounts, underscoring how quickly these identities can become hidden risk surfaces.
That risk is operational, not theoretical. A compromised application user can bypass intended separation of duties, trigger downstream actions with legitimate credentials, and survive long after the original application owner has changed. Zero Trust and access governance programs should therefore treat application users as first-class identities with ownership, logging, rotation, and revocation requirements, consistent with the control intent reflected in the NIST Cybersecurity Framework 2.0 and the governance patterns described in the Ultimate Guide to NHIs.
Organisations typically encounter the need to classify and constrain an application user only after a breach investigation, at which point the identity’s privileges and ownership become 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 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-01 | Application users are NHI workloads that need ownership, lifecycle, and least-privilege controls. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed and reviewed for non-human identities like application users. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires every workload identity, including application users, to be explicitly authorized. |
Inventory each application user, assign an owner, and restrict its permissions to the minimum needed.
