Accountability should sit jointly with identity engineering, cloud platform owners, and security governance, but one team must own the full control plane. Legacy tenants and OAuth permissions become dangerous when responsibility is fragmented across operations, application teams, and security review. Clear ownership is needed for app consent approval, privilege review, and remediation of risky inherited access paths.
Who should own legacy identity tenants and OAuth app permissions?
Accountability should not be split by convenience. Legacy tenants and OAuth app permissions need a single control-plane owner who can approve consent, review privilege, and force remediation when inherited access becomes unsafe. Identity engineering, cloud platform, and security governance all have a role, but one team must own the end-to-end control surface.
Why fragmented ownership creates the real failure mode
Legacy identity tenants often outlive the teams that originally created them. When operations manage the tenant, application teams manage the app, and security only reviews exceptions, no one is accountable for the full permission picture. That gap is where stale consents, overbroad scopes, and unattended inherited access paths accumulate.
OAuth app permissions are especially prone to drift because grants can survive long after the business reason for them has changed. If ownership is unclear, consent review becomes a paperwork exercise instead of a control that can revoke access, narrow scopes, or retire risky integrations.
What the accountable owner must actually control
The accountable owner needs authority over the full lifecycle, not just approval. That means knowing which apps are connected, who consented, what scopes were granted, which tenants still exist, and which inherited permissions should be removed or re-issued.
The practical boundary is simple: if a team cannot revoke access, rotate or retire the app path, and verify the result, it does not own the control plane. In mature environments, identity engineering often runs the mechanics, cloud platform owns the tenancy and integration layer, and security governance sets policy and escalation. The accountable owner is the function that can make the final decision and enforce it.
How to make accountability operational, not theoretical
Accountability becomes real when it is tied to review cadence, approval authority, and remediation deadlines. A clear owner should be able to answer three questions at any time: which OAuth apps are approved, which legacy tenants are still active, and which inherited permissions are awaiting removal.
That owner also needs a documented exception path for business-critical apps, because not every integration can be removed immediately. The difference between control and chaos is whether exceptions are time-bound, reviewed, and owned by the same team that can revoke them if the risk changes.
Risk and Threat Considerations
Legacy tenants and OAuth grants are high-value persistence paths because they can bypass normal user-facing controls and remain active after teams move on. The risk is not only overpermission, but also institutional memory loss, where nobody can explain why an integration still has access or whether that access is still justified.
Failure mechanism: ownership fragmentation lets old consent grants, inherited scopes, and dormant tenants survive without review, so attackers or careless admins can exploit standing access that should have been removed.
Impact: the organisation keeps an access path alive even after the original business need ends, increasing the blast radius of token theft, consent abuse, privilege escalation, and data exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Legacy tenants and OAuth grants require authoritative account and access ownership. |
| AC-6 — Least Privilege | OAuth scopes and inherited access should be minimized to reduce standing privilege. | |
| IA-5 — Authenticator Management | OAuth app secrets and tokens are identity-bearing material that need lifecycle control. | |
| Recommendation — Assign a named owner for each tenant and app grant, then enforce timely review and removal. Reduce app scopes to the minimum needed and remove unused inherited permissions. Rotate or retire app credentials on a defined schedule and after ownership changes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access decisions for tenants and app permissions need formal ownership and enforcement. |
| A.5.16 — Identity management | Legacy tenants and OAuth apps are identity subjects whose lifecycle must be governed. | |
| Recommendation — Define ownership for tenant and app access decisions, then enforce approval and review. Inventory identities tied to tenants and applications and keep ownership current. | ||
Practitioner Guidance
What to prioritise: assign one named owner for the control plane, then separate execution from accountability. Identity engineering can operate the process, but the accountable function must be able to approve, reject, and revoke without waiting on a committee.
What to verify: every legacy tenant and OAuth app should have an owner, an approver, a last-review date, and a clear revocation path. If any of those fields are missing, treat the permission as unmanaged until proven otherwise.
Common mistake: treating application teams as owners of the business use case while no one owns the tenant, consent grants, or inherited access. That split usually leaves risky permissions in place because each group assumes the other is watching it.
Practitioner takeaway: accountability should follow control, not just technical familiarity. The team that owns the right to approve and revoke access is the team that should own the risk.
