The customer remains accountable for what external applications can reach its tenant, even when an MSP or vendor operates the service. That means approval, review, suspension, and revocation need an explicit owner and a documented lifecycle. Shared operation does not remove the need for clear governance over the application identity.
Who Owns Third-Party App Access in a Microsoft 365 Tenant?
Accountability sits with the customer tenant, not with the MSP or application vendor that operates the integration. That means someone inside the tenant must own approval, review, suspension, and revocation decisions for every external app that can reach Microsoft 365 data or controls. Shared operation can delegate tasks, but it does not delegate governance.
That ownership needs to be explicit because tenant access is granted to an application identity, not just to a business relationship. If the tenant cannot name the owner, the approval path, and the revocation path, the organisation has lost control of who can act in its environment.
What Accountability Actually Covers
The practical question is not whether a partner can administer the app, but whether the tenant has a named authority for the lifecycle of that app. Accountability includes who approves initial consent, who validates business need, who checks scopes and permissions, and who can order removal when the relationship ends or the risk changes.
This is also where identity governance becomes important. IAM and IGA Basics is useful here because third-party app access follows the same governance pattern as other access decisions: define the owner, record the entitlement, review it on a schedule, and treat revocation as a first-class control rather than an emergency exception.
In Microsoft 365, the application can be operating under delegated trust, consented permissions, or service credentials, but the tenant still owns the exposure created by that trust. The fact that an MSP runs the service only changes who performs the work, not who is responsible for the access decision.
How to Govern Third-Party Access Without Losing Control
The safest operating model is to assign one accountable business owner and one technical control owner for each external application. The business owner should justify why the app exists; the technical owner should verify what it can reach, whether the permissions still match the use case, and whether the app is still present in the tenant because it is needed or merely because nobody removed it.
For teams managing many vendors, a Third-Party, B2B and Contractor Access Guide is the right model because it treats external access as a governed lifecycle, not a one-time onboarding event. The same discipline applies to partner apps, outsourced admins, and integrations that outlive the project that created them.
Review should focus on the relationship between access and business purpose. If the app no longer needs the scope it has, shrink it. If the app no longer has a clear owner, suspend it. If the app has not been reviewed recently, treat that as a governance gap even when no incident is visible.
When the external app is effectively part of a service chain, Federation and Trust Relationships Guide helps frame the hidden trust boundary. That boundary matters because a tenant often inherits risk from the partner’s authentication, token handling, and trust configuration even when the tenant did not build the application itself.
What Breaks When Ownership Is अस्पष्ट
When no one owns the lifecycle, the usual failure is not immediate denial of service, but silent accumulation of standing access. External applications remain consented, service principals persist, and dormant permissions survive long after the original need has passed.
Microsoft 365 Security Guide is relevant because tenant hardening is only effective when app consent, audit visibility, and review discipline are part of the operating model. Without that control layer, the tenant may know the app exists but still be unable to answer who approved it, why it still exists, or who should revoke it.
The operational consequence is simple: unclear ownership turns routine access into accumulated trust. In a breach, that uncertainty slows containment because teams waste time deciding who can suspend the app, who can validate blast radius, and who has the authority to remove it.
Risk and Threat Considerations
Third-party application access is a common place for tenant exposure to persist because attackers and careless integrations both benefit from long-lived trust. If consent, scope, and revocation are not tightly owned, a partner app can keep reaching mail, files, or directory objects long after the original business need has ended.
Failure mechanism: The tenant treats vendor operation as if it also transfers accountability, so no one reviews permissions, rotates secrets or tokens, or removes stale consent when the app should be retired. That leaves the application identity as a durable access path even when the business relationship has changed.
Impact: A compromised or over-entitled external app can become a tenant-wide foothold for data access, privilege abuse, and persistence, and incident response becomes slower because ownership of the revocation decision is unclear.
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 surface, CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Third-party app access is an external identity governance problem in cloud tenants. |
| Recommendation — Assign and review external application access through governed IAM ownership and lifecycle controls. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | External app access requires lifecycle ownership, approval, and revocation decisions. |
| IA-5 — Authenticator Management | Microsoft 365 integrations often rely on tokens, secrets, or certificates that need lifecycle control. | |
| Recommendation — Maintain accountable ownership for third-party application accounts and revoke them when no longer needed. Track and rotate authenticators used by third-party applications before they become standing access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Tenant access by external applications must be authorised, reviewed, and withdrawn under access control. |
| Recommendation — Define and enforce access approval and revocation for external applications in the tenant. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Third-party apps must be removed promptly when the business need or relationship ends. |
| Recommendation — Revoke external application access during offboarding and retire unused service identities. | ||
Practitioner Guidance
What to verify: For every external app, confirm three things before you trust it: who owns approval, who owns technical review, and who can revoke it without waiting for the vendor. If any one of those is missing, the access path is not fully governed.
Decision rule: If the app can reach production tenant data or administrative controls, treat it as a governed entitlement, not a vendor convenience. If the owner cannot be named in one sentence, suspend the app until ownership is assigned.
What good looks like: Each third-party app has a named business sponsor, a technical custodian, a recorded permission set, and a review or offboarding trigger tied to contract end, scope change, or inactivity.
Practitioner takeaway: The key control is not who runs the integration day to day, but who is accountable when access must be approved, narrowed, or removed.
Related resources from NHI Mgmt Group
- Who is accountable when third-party remote access is overused in public safety environments?
- Who is accountable for third-party access after a campaign or project ends?
- Who is accountable when a user grants a risky third-party app access?
- Who is accountable when a third-party risk control fails to revoke access?