They should treat it as identity revocation across the full platform boundary. If access is removed from the core app but persists in connected miniapps or downstream systems, the platform leaves orphaned privilege behind. Effective offboarding has to close every path that inherits the original verified identity.
Why superapp offboarding has to revoke identity, not just remove the app
A superapp usually sits above a set of connected miniapps, shared sessions, APIs, and downstream entitlements. That means offboarding is only complete when the verified identity is revoked at the platform boundary and any inherited access is removed everywhere it can still be used. If teams only delete the front-door account, they can leave active privilege behind in connected services.
The practical test is simple: if the user, contractor, or partner could still act through a miniapp, token, or delegated session after the core app is removed, the offboarding was incomplete. In a platform model, the original identity relationship is what must be closed, not just one interface to it.
What fails when offboarding stops at the superapp shell
The main failure mode is orphaned access. Superapps often have one authoritative identity, but multiple execution paths, so a removed front-end account can still leave valid tokens, scoped permissions, cached sessions, or child-app authorizations in place. That is especially dangerous when one login fans out into messaging, payments, support, commerce, or internal admin functions.
Teams should assume that removal from the main UI does not equal revocation of the underlying authority. The right control question is whether every downstream path was tied back to the same identity lifecycle event and actually invalidated, including API tokens, refresh tokens, sessions, and app-specific grants.
What good offboarding looks like across a platform boundary
Good offboarding follows the access path, not the product boundary. The identity owner should identify every connected app, delegated token, and trust relationship that inherits from the original account, then revoke or expire each one in the same workflow. Where there is shared infrastructure, the revocation step should also cover service-linked access that was created on behalf of the leaving user.
- Revoke the primary identity and its active sessions.
- Invalidate downstream tokens, app grants, and refresh mechanisms.
- Confirm miniapps, partner apps, and embedded workflows no longer accept that identity.
- Verify that audit logs show closure of the full access chain, not just the front-end account.
For identity lifecycle discipline, the useful comparison is to a joiner-mover-leaver process: the leaver event is not complete until all inherited permissions are removed, not merely hidden from the user interface. NHIMG’s Joiner-Mover-Leaver (JML) Guide is a practical reference for that lifecycle view, and the broader IAM and IGA Basics guide helps frame why entitlement cleanup must follow the identity itself.
Risk and Threat Considerations
When offboarding is treated as application removal, the platform can retain dormant but still-authorized access paths. That creates a direct exposure window for misuse, especially if the old identity can still reach sensitive miniapps, delegated actions, or high-value backend functions.
Failure mechanism: A central account is disabled while downstream grants, tokens, and sessions remain valid in child apps or connected systems, so the platform still trusts the departing identity through inherited authority.
Impact: The organization can end up with orphaned privilege, delayed detection of unauthorized use, and incomplete revocation of access across business-critical workflows. In a breach scenario, that can turn a routine offboarding gap into persistent access for an attacker or ex-user.
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 | IA-5 — Authenticator Management | Covers revocation and lifecycle of tokens, keys, and sessions used by the leaving identity. |
| AC-2 — Account Management | Directly addresses deprovisioning and closure of accounts and associated access on departure. | |
| AC-6 — Least Privilege | Supports ensuring no residual or inherited permissions remain after the user leaves. | |
| Recommendation — Revoke authenticators and invalidate credentials tied to the departing identity across all linked apps. Remove the account and its associated access rights from every connected system during offboarding. Eliminate excess inherited privileges so departing identities retain no unnecessary access. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Applies to removing and reviewing access rights when a user or contractor leaves. |
| A.5.16 — Identity management | Covers lifecycle governance for identities across the platform boundary. | |
| Recommendation — Revoke access rights promptly across the superapp and all dependent services. Tie offboarding to identity lifecycle controls, not just application deletion. | ||
Practitioner Guidance
What to verify: Confirm that the offboarding workflow revokes the authoritative identity, not just the superapp account, and that it also invalidates every token, session, and child-app grant issued from that identity. If the platform cannot prove that closure, treat the offboarding as incomplete.
Decision rule: If a miniapp can still act on behalf of the former user after the core account is removed, prioritize downstream revocation and access-chain validation over UI-level deactivation. If the platform uses multiple trust domains, require evidence from each one before declaring the identity closed.
Practitioner takeaway: Superapp offboarding is an identity lifecycle event with platform-wide blast radius, so the control objective is complete authority revocation and provable inheritance cleanup, not account deletion.
Related resources from NHI Mgmt Group
- How should teams govern machine identity revocation and offboarding?
- Who should own offboarding and access revocation when multiple teams manage identity and remote access?
- Should teams treat server-side application permissions as part of identity governance?
- Should security teams treat MCP issues as application bugs or identity governance problems?
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 October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org