A fourth-party app is a software service used by a third-party supplier to deliver its own product or service. It sits one step beyond the direct vendor relationship, so its data flows, integrations, and access can affect the original customer even when the customer does not contract with it directly.
What a fourth-party app is in practice
A fourth-party app is not usually visible to the original customer, but it can still shape how the supplier delivers the service. That makes it a useful way to describe hidden dependencies in SaaS, integrations, and delegated workflows where the real data path extends beyond the direct contract.
The key point is that the customer’s exposure is no longer limited to the named vendor. If the supplier relies on another application for messaging, storage, analytics, support automation, or identity-related workflows, that downstream app can inherit the same sensitivity as the primary service.
Why fourth-party apps matter to third-party risk
Fourth-party apps expand the trust boundary without extending the customer’s contract or visibility. They can receive customer data, process tokens or secrets, or participate in operational workflows that the customer assumes are handled only by the direct supplier.
This is why fourth-party risk often appears in subprocessor lists, integration inventories, and contract flow-downs. It is also why mapping only the direct vendor is incomplete when the supplier’s own tooling can create new concentration points, hidden dependencies, or data-sharing paths. For a structured way to think about those dependencies, see the Fourth-Party and Nth-Party Risk Guide.
Where the supplier’s workflow depends on external SaaS or OAuth-connected tools, visibility gaps can be especially acute. Discovery work should therefore include the supplier’s app ecosystem, not just the top-level contract, which is the focus of the Shadow SaaS and Unsanctioned App Discovery Guide.
How fourth-party apps affect data, access, and integrations
Fourth-party apps often matter because they sit in the middle of real operational flows. They may handle tickets, sync records, send notifications, enrich customer data, or store API credentials that let the supplier automate work. That means they can affect confidentiality, integrity, and availability even when they are invisible to the original customer.
Access paths are especially important. If a supplier grants broad OAuth scopes, API permissions, or delegated access to a downstream app, the app may gain more data or control than the customer intended. The same concern applies when the supplier’s own administrators can approve or retain integrations without strong review. See the Entra ID Applications and Consent Guide for the access-control mechanics behind app consent and delegated permissions.
In practice, fourth-party app reviews should also look at token storage, offboarding, and app-to-app connectivity. A supplier that cannot answer where integrations are registered, how scopes are limited, or how access is revoked may be unable to describe the true service chain. The SaaS Integration Security Questionnaire Template gives a practical model for that conversation.
How to govern and assess fourth-party exposure
Governance starts with asking suppliers to name the services they rely on to deliver the contracted product, then identifying which of those services can touch customer data, credentials, logs, or support workflows. The goal is not just vendor inventory, but a defensible view of where the supplier’s dependencies alter your own risk posture.
That assessment is stronger when fourth-party review is built into third-party risk management rather than treated as an exception. Maturity models help organisations move from ad hoc questions to repeatable controls, evidence, and escalation paths, which is the purpose of the Third-Party Risk Management Maturity Model.
For organisations with regulated operational resilience requirements, fourth-party visibility also needs to support continuity and exit planning. A supplier’s hidden dependency can become your service outage if it fails, so fourth-party mapping belongs in concentration analysis and exit design, not just procurement review. The Cloud Concentration Risk and Exit Strategy Guide is useful where dependency chains become systemic.
Common failure patterns and where to look next
The most common failure pattern is believing the direct vendor is the whole story. In reality, the supplier may depend on analytics tools, support platforms, identity apps, or outsourced processors that inherit customer data and operational trust. Another common failure is assuming contractual clauses alone reveal the dependency chain when technical discovery is still incomplete.
For practitioners, the next question is usually whether the supplier can prove which downstream apps are approved, what they can access, and how quickly they can be removed. If the answer is vague, the fourth-party relationship is already part of the exposure, even if it is not yet part of the contract file. That is why app review, consent governance, and offboarding evidence should sit alongside vendor due diligence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-04 — Supply Chain Risk Management | Fourth-party apps extend supplier dependency chains and require supply-chain visibility. |
| ID.AM-01 — Physical Devices and Systems Inventory | Fourth-party exposure depends on knowing which systems and apps sit in the service chain. | |
| Recommendation — Map supplier dependencies and require evidence for downstream app oversight. Inventory the supplier-linked applications that can touch your data or workflows. | ||
| NIST SP 800-53 Rev 5 | SR-5 — Supply Chain Development and Acquisition | Fourth-party apps are part of the acquisition and supplier-risk chain needing oversight. |
| CA-3 — System Interconnections | Integration paths and delegated connections define the fourth-party exposure surface. | |
| Recommendation — Require suppliers to disclose and manage downstream service dependencies. Document and review interconnections that extend beyond the direct vendor. | ||
| ISO/IEC 27001:2022 | A.5.22 — Monitoring, review and change management of supplier services | Fourth-party services change supplier delivery risk and need review and monitoring. |
| Recommendation — Track supplier service changes that introduce new downstream dependencies. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org