What should security teams do first when legacy tenants still exist in the environment?

Start by inventorying every legacy and non production tenant, then verify that modern controls apply everywhere, not just in current production systems. Prioritise MFA enforcement, review OAuth and integration permissions, and remove any standing access that is broader than needed. Legacy environments often become the easiest entry point when they are treated as low risk or forgotten.

Why legacy tenants should be treated as an active security inventory problem

Legacy tenants are often overlooked because they are not in the main production path, but they still carry authentication, authorization, and integration risk. The first useful move is to inventory them as live security assets, not historical artefacts, and confirm whether they still trust current identity controls, token policies, and admin paths. That means checking whether the tenant can still reach modern systems, not just whether it is still used.

A tenant that is “old” is not automatically lower risk. Forgotten environments commonly retain broad permissions, weaker MFA coverage, stale OAuth grants, and integration paths that were never re-reviewed after migration. If those paths still authenticate to business systems, they remain part of the attack surface.

Where legacy tenants still exist, the security question is usually not whether they are obsolete, but whether they are isolated, governed, and observable. The right starting point is complete visibility, because you cannot safely reduce standing access or decide what to retire until you know which tenants still hold trust relationships.

What to verify before you assume the tenant is safe

Start by proving whether each tenant is covered by the same control baseline as current production, including MFA, conditional access where applicable, logging, and privileged access review. This is especially important for legacy or non production environments because they often evade standard control rollouts, then become the easiest route into higher-value systems.

Review OAuth grants, app registrations, service principals, API tokens, and other integration permissions with the same seriousness as human admin access. If the tenant still carries standing access into core systems, the practical risk is not age, it is privilege persistence. Any exception should be explicit, documented, and limited by purpose and scope.

For legacy tenants that cannot immediately be retired, the minimum safe posture is bounded access, strong authentication, and a clear owner for every trust relationship. A tenant with no owner and no recent control review should be treated as unresolved exposure, not as dormant infrastructure.

Risk and Threat Considerations

Legacy tenants are attractive to attackers because they often combine weak governance with overlooked permissions. A tenant that bypasses current MFA, still trusts old integrations, or retains broad standing access can provide an easier initial foothold than a modern production tenant with tighter controls.

Failure mechanism: Security teams miss a tenant during migration or decommissioning, so stale authentication methods, excessive OAuth scope, or inherited admin access remain active. That creates a low-friction path for compromise, lateral movement, or misuse of trusted integrations.

Impact: Compromise of a neglected tenant can expose production systems, cloud resources, or connected apps, and may also undermine confidence in the migration boundary itself. The longer the tenant remains unmanaged, the more likely it is to accumulate hidden access paths and unrevoked trust.

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 CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secret and Credential Management	Legacy tenants often retain tokens, keys, and OAuth grants that remain valid.
	NHI-02 — Identity Lifecycle and Offboarding	The question centers on discovering and retiring tenants that still exist in the environment.
	NHI-03 — Authorization and Least Privilege	Legacy tenants commonly keep broader access than current production systems require.
Recommendation — Inventory and rotate tenant-bound secrets before allowing continued access. Track every tenant through ownership, review, and decommissioning. Reduce tenant permissions to the minimum access needed for each integration.
NIST CSF 2.0	GV.RM-03 — Cybersecurity Risk Management Strategy	Legacy tenants should be treated as managed risk assets with explicit ownership and prioritisation.
	PR.AA-01 — Identity Management, Authentication, and Access Control	The issue depends on whether MFA and access controls apply consistently across tenants.
Recommendation — Classify legacy tenants in the risk register and assign remediation priority. Enforce the same authentication and access controls across all tenants.
CIS Controls v8	6.3 — Access Management Lifecycle	Legacy tenants need ownership, review, and timely removal of standing access.
	6.4 — Account and Access Review	The question requires checking which tenants still have active permissions and integrations.
	4.9 — Secure Configuration of Enterprise Assets and Software	Legacy tenants often diverge from current baseline controls and configuration standards.
Recommendation — Revoke or revalidate tenant access on a defined lifecycle schedule. Review tenant permissions and integrations for unnecessary access. Bring legacy tenants back to the current security baseline or isolate them.

Practitioner Guidance

What to prioritise: Build a complete tenant register first, then rank tenants by whether they still authenticate to production systems, carry privileged access, or host third-party integrations. Those three conditions matter more than whether the tenant is currently “in use.”

What to verify: Confirm that MFA is enforced, OAuth permissions are still justified, and every standing access path has a named owner and an expiry or review date. If you cannot prove any one of those points, treat the tenant as still live for security purposes.

Common mistake: Teams often secure the new tenant set while leaving old tenants on inherited trust. That creates a control gap where the environment is only as strong as the least governed legacy entry point.

Practitioner takeaway: The first step is not cleanup, it is control parity, because a legacy tenant is only “legacy” if its access paths are already constrained to the same standard as everything else.