TL;DR: A modular SuperApp can unify identity, transactions, and auditability across citizens, public authorities, and companies, while supporting GDPR, NIS2, and DORA requirements through a shared platform architecture, according to KOBIL. The governance challenge is that consolidation changes the control plane for identity and access, not just the user experience.
NHIMG editorial — based on content published by KOBIL: Digital processes, mobile usage, and connected ecosystems in a SuperApp model
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams govern a SuperApp that aggregates multiple services?
A: Treat the SuperApp as an identity and audit control plane, not as a user interface.
Q: Why do integrated platforms create new IAM governance risks?
A: Integrated platforms reduce duplication, but they also concentrate identity, data, and transaction control into one place.
Q: How should organisations govern superapps used for regulated workflows?
A: They should treat the superapp as a governed identity and evidence layer, not just another application.
Practitioner guidance
- Define the platform as a governed identity plane Classify the SuperApp as a control layer with explicit ownership for authentication, authorisation, logging, and revocation across every MiniApp and integration.
- Map every MiniApp to least-privilege scopes Require component-level scopes, API entitlements, and offboarding paths so one shared login does not become one shared over-permissioned access model.
- Correlate audit evidence across services Standardise correlation IDs, immutable logs, and retention rules so an action can be reconstructed after it crosses the service bus and API gateway.
What's in the full article
KOBIL's full guide covers the implementation detail this post intentionally leaves for the source:
- Technical architecture specifics for the service bus, API gateway, and MiniApp framework
- Regulatory positioning details for GDPR, NIS2, DORA, and eIDAS across public and private sector use cases
- Best-practice deployment examples for banking, municipalities, and developer ecosystems
- Developer ecosystem guidance for building, integrating, and monetising MiniApps within the platform
👉 Read KOBIL’s full guide to its SuperApp identity, audit, and compliance model →
SuperApp identity governance: are integrated platforms changing IAM?
Explore further
Platform consolidation does not eliminate identity risk, it relocates it. When a SuperApp becomes the primary access layer, the governance burden shifts from scattered point solutions to one shared trust plane. That can improve visibility, but it also means IAM failure, audit failure, or privilege creep affects every connected service at once. Practitioners should evaluate consolidation as a change in control topology, not as a reduction in risk.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why shared platform identity layers need lifecycle controls as well as login controls.
A question worth separating out:
Q: How do MiniApps affect least-privilege design?
A: MiniApps can help keep functionality modular, but they only support least privilege if each component has narrow entitlements, a named owner, and a clean revocation path. Shared identity should not mean shared access. The governance model has to stay granular at the application and API level.
👉 Read our full editorial: KOBIL’s SuperApp model reframes identity, audit, and platform governance