How Enravo Core manages app instances through a four-stage lifecycle with admin approval workflows and instant revocation.
When a user installs your app and opens it for the first time, what happens? In most systems, nothing — the app just works. In Enravo Core, the app enters a lifecycle. Every app instance is tracked, verified, and managed through four stages: Pending, Active, Revoked, and Banned.
An app instance is more than a user session. It represents a specific installation on a specific device. By tracking instances individually, Enravo Core can enforce device limits, detect suspicious patterns (like 50 installations from the same IP in an hour), and revoke access at the device level — not just the user level.
Each client type can configure its own activation mode. Consumer apps typically use auto-activation — the first launch registers the instance and activates it immediately. Enterprise or internal apps might require admin approval, where the instance stays in Pending until an administrator reviews and approves it.
id: enterprise_internal
activation_mode: admin_approval
max_pending_duration: 48h # auto-reject if not approved
notification:
on_pending: [admin_email, slack_webhook]
on_activation: [user_push]Auto-activation with attestation is the recommended mode for consumer apps. The app activates automatically, but only after passing Play Integrity (Android) or App Attest (iOS) verification. This prevents modified or sideloaded apps from activating.
Revocation is a soft action — the app instance loses access but can be reactivated. This is useful when a user reports a lost device, or when you need to temporarily disable an app version while deploying a fix. All active sessions are immediately invalidated, but the device registration is preserved.
Banning is permanent enforcement. It's triggered automatically by the threat detection system (nonce replays, repeated signature failures) or manually by an admin investigating suspicious activity. A banned instance cannot make any API requests, and the ban is linked to both the device ID and the device's public key, preventing re-registration.
The app lifecycle is directly connected to device limits. Each client configuration specifies a maximum number of active devices per user. When the limit is reached, the overflow behavior determines what happens: 'block' mode rejects the new device, 'replace' mode deactivates the oldest active device to make room.
This is tracked at the instance level, not the session level. A user with 3 active devices and a limit of 3 can log in and out freely on those devices. But logging in on a 4th device triggers the overflow policy.
Every lifecycle transition is recorded in the audit trail: when the instance was created, when it was activated, by whom (auto or admin), when it was revoked or banned, and the reason. This creates a complete history of every app instance in the system, essential for security investigations and compliance requirements.
App lifecycle management is one of those features that sounds simple but requires deep infrastructure support. It touches authentication, device management, threat detection, and admin workflows. In Enravo Core, all of these are built into the same system — because security features that don't work together don't work at all.