A trusted app is a third-party application that has been granted approved access under an organisation’s policy. In practice, trusted status means the app can operate with the permissions assigned to it, so it requires ownership, review, and periodic validation to ensure access still matches business need.
Expanded Definition
A trusted app is not simply a permitted app; it is a third-party application that has been granted approved access under an organisation’s policy and therefore operates with assigned permissions that must be owned and reviewed. In NHI and IAM practice, trusted status is a governance label, not a statement that the software is inherently safe. It usually implies the app can call APIs, read data, or trigger workflows on behalf of users or systems, which makes the approval boundary more important than the vendor’s brand or the app’s popularity.
Definitions vary across vendors, especially when identity governance tools, SaaS marketplaces, and agentic AI platforms use “trusted” to mean different levels of consent or risk acceptance. In disciplined environments, a trusted app should have a documented business purpose, a named owner, a scoped permission set, and a scheduled revalidation cycle. The control question is whether the access still matches current need, not whether the app was once approved. For broader governance context, the NIST Cybersecurity Framework 2.0 reinforces the need to govern access as an ongoing function rather than a one-time approval.
The most common misapplication is treating “trusted” as a permanent trust signal, which occurs when approvals are never revisited after scope, ownership, or vendor behaviour changes.
Examples and Use Cases
Implementing trusted-app governance rigorously often introduces review overhead and user friction, requiring organisations to weigh faster workflow enablement against tighter control of third-party access.
- A collaboration app is approved to read calendar metadata and post notifications, but not to access mailbox contents, with the scope documented in the access register.
- A finance automation app is trusted for invoice ingestion only after the owner confirms the app’s data path, storage model, and revocation process.
- An AI productivity assistant is allowed to use a limited set of APIs, while higher-risk actions such as exporting records require separate approval and monitoring.
- A SaaS integration is revalidated after a merger changes the business owner, because trusted status should follow current accountability, not historical consent.
- A security team cross-checks approved third-party integrations against lifecycle guidance in the Ultimate Guide to NHIs and then maps the resulting entitlement review into NIST Cybersecurity Framework 2.0 governance activities.
In mature environments, trusted-app reviews also consider whether the application behaves like a human-consented tool or a machine identity with durable access, because that distinction affects logging, rotation, and offboarding expectations.
Why It Matters in NHI Security
Trusted apps are a common entry point for NHI risk because they often sit between business productivity and privileged data access. Once approved, they may retain broad permissions even when the original use case no longer exists, which creates shadow access paths that are difficult to detect. This matters in NHI security because third-party integrations can operate with non-human credentials, long-lived tokens, or delegated OAuth grants that outlast operational need. The governance failure is not the app itself but the assumption that approval equals safety. NHIMG research shows that 92% of organisations expose NHIs to third parties, raising supply chain security concerns, and the Ultimate Guide to NHIs also notes that only 20% have formal processes for offboarding and revoking API keys.
Trusted-app oversight is therefore part of access containment, secret hygiene, and identity lifecycle governance. Without periodic validation, an approved app can become the least visible route to excessive privilege, data leakage, or persistence after termination. Organisational teams typically encounter the blast radius only after a compromised integration, vendor change, or unexplained data exposure, at which point trusted-app review 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 OWASP Agentic AI Top 10 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-02 | Trusted apps often depend on exposed secrets and overbroad permissions. |
| NIST CSF 2.0 | PR.AC-4 | Approved app access must be managed and revisited as part of access governance. |
| NIST Zero Trust (SP 800-207) | SC-7 | Trusted apps still require continuous verification, not implicit trust. |
| NIST SP 800-63 | AAL2 | Delegated app access should reflect the assurance needed for the protected action. |
| OWASP Agentic AI Top 10 | LLM-04 | Agentic apps with tool access can become trusted integrations without sufficient review. |
Review approved app access, secret handling, and revocation readiness for every third-party integration.
Related resources from NHI Mgmt Group
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
