Skip to main content

Admin Safeguard: Verification for Destructive Actions

Swif.ai gives administrators the ability to remotely wipe devices, perform soft wipes, and remove users. Because these actions are irreversible and high‑impact, we've added an additional layer of protection called Admin Safeguard — a two‑factor verification step that ensures no destructive action can be carried out without confirming the admin's identity first.

This article explains how Admin Safeguard works, how to configure it, and what your admins can expect.

1. What Is Admin Safeguard?

Admin Safeguard is a setting that requires admins to verify their identity via a one‑time email code before executing any of the following actions:

  • Device Wipe — Remotely erases a device.

  • Soft Wipe — Performs a selective wipe of a device.

  • Remove User — Deletes a user account.

When enabled, the destructive action is blocked until the admin enters a valid verification code. This prevents accidental execution and adds a strong safeguard against unauthorized use — even if an admin session is compromised.

2. How to Enable or Disable Admin Safeguard

Admin Safeguard is managed under Settings → Security.

  • Setting name: "Require verification before device wipe, soft wipe, and remove user"

  • Default: ON (enabled)

When the toggle is ON, all three destructive actions require 2FA verification before they execute. When the toggle is OFF, the actions proceed with the standard confirmation dialog only — no verification code is required.

The setting persists across browser refreshes and re‑logins.

3. How the Verification Flow Works

When Admin Safeguard is enabled, the flow for device wipe, soft wipe, and remove user follows the same pattern:

Step 1 — Initiate the action

The admin clicks the action button, which displays "Continue" instead of "Wipe Data" or "Delete." This signals that an additional verification step is required before the action executes.

Step 2 — Enter verification code

A verification modal appears. Swif.ai sends a one‑time code to the admin's registered email address. The admin enters the code in the modal and submits it.

Step 3 — Action executes

Once the backend confirms the code is valid, the destructive action is carried out and a success confirmation is shown.

At no point during this flow is the destructive action triggered without a valid code.

4. What Happens When Admin Safeguard Is Off

When the setting is toggled OFF, all three actions revert to their original behavior:

  • Device Wipe / Soft Wipe displays the original "Wipe Data" button.

  • Remove User displays the original "Delete" button.

  • Clicking the button shows a standard confirmation dialog — no verification modal, no email code.

This ensures full backward compatibility with the existing workflow for organizations that prefer not to use the extra verification step.

5. Error and Edge‑Case Handling

Swif.ai handles all failure scenarios gracefully. The destructive action is never executed unless a valid code is confirmed.

  • Invalid code

    • An inline error is displayed near the code input field.

    • The modal stays open so the admin can retry.

  • Expired code

    • An error message informs the admin the code has expired.

    • The admin is prompted to request a new code.

  • Too many attempts (rate limiting)

    • An error is shown and further submissions are blocked.

    • This prevents brute‑force attempts against the verification code.

  • Generic failure

    • A non‑specific error message is displayed, advising the admin to retry.

    • The destructive action is not executed.

  • Resend code

    • A "Resend code" link is available in the verification modal.

    • A toast notification confirms the new code has been sent.

    • A cooldown period may apply before the code can be resent again.

If the admin closes the verification modal (via the close button or Escape key) without completing verification, no action is taken. Re‑initiating the flow starts a fresh verification (a new code is required).

6. Summary

Admin Safeguard adds a critical identity‑verification layer on top of Swif.ai's existing protections for destructive device management actions:

  • Identity verification — Admins must confirm their identity via a one‑time email code before any device wipe, soft wipe, or user removal.

  • Default‑on protection — The setting is enabled by default, so new organizations are protected out of the box.

  • Backward compatible — Organizations that prefer the standard confirmation‑only flow can disable the setting at any time.

  • Graceful error handling — Invalid codes, expired codes, rate limits, and network failures are all handled safely. The destructive action never executes without a valid code.

Admin Safeguard works alongside Swif.ai's existing infrastructure‑level protections — including BYOD shielding, per‑IP rate limiting, and agent‑side loop prevention — described in How Swif.ai Protects Critical APIs.


Did this answer your question?