Butterfly Security for iOS

The first card is the resilience score for the active connection, shown as a number out of 100 with the contributing factors listed underneath. Below it: the most recent backup with its status, age, and per-resource counts; a 7-day drift summary split into total, critical, and warning changes, with the three most recent changes named; and Quick actions with Run backup and Find user.

Pull to refresh re-reads all three. Run backup starts a real backup on the connection and reports the new backup identifier.

Search by email or Okta login. Results are debounced and start at two characters. Tapping a person opens the user detail screen: profile, current status, last sign-in, and when the status last changed.

The Actions grid holds six buttons. Suspend user flips to Unsuspend user when the person is already suspended. The rest are Send password reset, Expire password, Unlock account, Clear all sessions, and Deactivate user. Each one opens a confirmation sheet that states the consequence in plain language before anything happens, for example “Signs the user out of all devices immediately” for Clear all sessions.

Deactivate is treated differently. It opens a full sheet rather than a dialog and requires you to type the target user’s email address exactly before the destructive button enables. Actions your Okta integration has not been granted show a lock badge and do not respond to taps.

Below the action grid, the same screen lists the user’s group memberships and application assignments, each with a remove control. That is the fastest path to revoking one specific access without touching the account itself.

Both are searchable lists over the active org. Opening a group gives you an Add a member field: search for a person by email or login and add them with one tap. Opening an application gives you the same thing for assignment, plus the app’s sign-on mode and status.

Removal runs from the user detail screen described above, so the mental model stays consistent. You add from the group or app, and you remove from the person.

Every network zone on the org with its type, usage (blocklist zones are marked), and gateway ranges. The toggle activates or deactivates the zone, which is how you enforce or lift a block on an IP range mid-incident. The screen confirms the new state after the change lands.

A read-only view of the Okta system log for the active org: severity, event type, the human-readable message, the actor, and how long ago it happened. Useful for confirming that the action you just took actually registered in Okta, and for seeing what someone else changed.

A stats header (total, completed, failed, success rate) over the backup history, each row showing status, age, resource counts, size, and any error message. The Run button in the toolbar opens a sheet to start a new backup. While a backup is running, opening it shows live progress that polls until the run finishes.

Opens against the most recent completed backup, or from any completed backup in the Backups tab. It shows when the snapshot was taken, which org it came from, and a per-resource-type count of what a restore would cover.

The last card on the screen states plainly that execution stays on the web app, and why. If no completed backup exists yet, the screen tells you to run one first.

A summary sized for a leadership update: recovery score, time since the last completed backup, critical drift count over 7 days, and a status pill. It includes a share sheet that exports the summary as plain text you can paste into an incident channel or a board update, plus a suggested next action derived from whichever signal is weakest.

Ask a disaster-recovery question and get an answer grounded in indexed Okta recovery material and your own backed-up configuration, with the retrieved sources listed and a match percentage on each. The same screen carries an AI readiness score out of 100 for the active connection, broken into factors, with a recommended next step. When the knowledge base is unreachable the screen says so rather than answering silently from nothing.

The biometric requirement toggle, theme selection, the active connection with a Switch connection control, and a read-only list of every Okta scope currently granted to this connection. That scope list is the fastest way to answer “why is this button locked.”

Settings also holds Sign out and Delete account. Account deletion is permanent, requires typing DELETE and a biometric confirmation, and removes your profile and sign-in identity, all sessions across devices, stored device tokens, and account activity records within the retention window.

Before submitting any change, the app calls LAContext.evaluatePolicy(.deviceOwnerAuthentication), which presents the system Face ID, Touch ID, or passcode prompt with the specific action named in it (for example “Suspend user Jane Doe”). Only when that succeeds does the client attach the header X-Biometric-Confirmed: 1 to the request.

The server checks that header first, before it parses the request body and before it loads your session context. The value must be exactly 1. Anything else, including a missing header, returns 412 Precondition Failed.

412 is the correct status here and the choice is deliberate. Your session is valid and you are authorized. What failed is a precondition on this specific request. A stolen session cookie replayed from outside the app cannot probe the mutation surface at all, because the check runs before anything else. Read requests do not carry the header and do not need it.

Every mutation declares the Okta scope it requires. The server reads the granted-scope list recorded on the connection when it was last capability-tested, and compares. If the scope is absent, the request fails immediately with 403 and a structured body, with no round trip to Okta:

{
  "ok": false,
  "error": "scope_required",
  "scope": "okta.users.manage",
  "remediation": "Customer admin must grant okta.users.manage to the OIN install. See /docs/okta/oin/api-service-integration#scopes."
}

The app reads that body and shows you the remediation text verbatim, so the message on screen names the exact scope to grant rather than a generic permission error. Before you get that far, the same capability data disables the button and marks it with a lock badge, so an ungranted action is visibly unavailable rather than a failure you discover by trying.

If a connection has never been capability-tested, the granted-scope list is empty and every mutation is refused. Run the scope test once from the web app and the app picks it up.