figma guide
Designing break-glass emergency access and account recovery UI in Figma: bypass flows, audit, and handoff
Design break-glass emergency access and account recovery UI in Figma with SSO bypass, IP allowlist override, time-boxed elevation, dual approval, and Dev Mode specs for enterprise security admin.
- Published
- Updated
- Jul 17, 2026
- Read time
- 7 min
- Level
- Intermediate
Quick answer
Break-glass flows let designated admins regain access when SSO, IP allowlists, or lockout policies block normal login—configured under Organization → Security → Emergency access. Design a break-glass eligibility matrix (who, which scenarios, max duration); recovery entry points on login blocked screens and in org Security settings; step-up verification (passkey, hardware key, or backup codes) before elevation; time-boxed session with countdown and auto-revoke; dual approval for sensitive overrides; and immutable audit events in security activity. Start from the Figma guides hub and pair with SSO, IP allowlist, 2FA, and session timeout.
Who this is for
- Product designers building enterprise login recovery, org lockout prevention, and Security admin consoles.
- Design system teams aligning emergency banners with inline alerts and countdown UI with progress indicators.
- Engineers implementing time-boxed tokens, dual-approval webhooks, and audit immutability for compliance reviews.
Break-glass scenarios and entry points
| Scenario | Typical trigger | Entry point |
|---|---|---|
| SSO IdP outage | Enforce SSO on; IdP unreachable | Login page → “Emergency admin access” |
| IP allowlist lockout | Admin travels; VPN down | Login blocked screen |
| MFA device loss | Owner locked out of 2FA | Security settings recovery |
| Mass account lockout | Brute-force policy misfire | Org Security → Emergency access |
| DLP false positive | Critical share blocked mid-incident | DLP break-glass approval |
Verdict: one Emergency access hub in org Security plus contextual links from login blocked states—do not hide recovery behind support tickets only.
Eligibility and policy table
| Column | Spec | Notes |
|---|---|---|
| Role | Owner, Security Admin only | Max 3 eligible accounts |
| Scenario | SSO bypass, IP override, DLP exception | Checkbox per scenario |
| Max session | 15 min – 4 hr | Default 1 hr |
| Dual approval | Required / Optional / Off | On for SSO bypass |
| Cooldown | Min hours between uses | Default 24 hr per user |
| Notify | Email Security distribution list | Cannot disable |
| Audit retention | Immutable, 7 yr | Link compliance exports |
EmergencyAccessPolicyTable
├── Toolbar: [ Edit policy ] [ View audit ] [ Run tabletop test ]
├── Rows: SSO bypass · IP override · DLP exception · Account unlock
└── Footer: "3 eligible admins · Dual approval on for SSO bypass"
Show last tabletop test date—compliance teams expect proof admins can actually recover.
Login blocked → break-glass path
When IP allowlist or SSO enforcement blocks login:
LoginBlockedScreen
├── Headline: Sign-in blocked by organization policy
├── Reason: Your IP (203.0.113.44) is not on the allowlist
├── Primary help: Connect to Acme VPN · IT contact link
├── Secondary: Are you a designated emergency admin?
└── Link: Request emergency access →
Request emergency access opens a focused wizard—not the full login form:
BreakGlassWizard — Step 1 of 4
├── Email: [ admin@acme.com ]
├── Scenario: (•) IP allowlist override ( ) SSO bypass
├── Note: "VPN outage — need to disable bad CIDR rule"
└── [ Continue ]
Step 2: Verify identity with passkey, TOTP, or pre-registered backup codes—never password alone when SSO is enforced.
Step 3: Dual approval (if required)—second Security Admin receives push/email with request summary and 15-minute approve window.
Step 4: Active session banner with countdown and scoped permissions list.
Time-boxed elevation session
| UI element | Spec |
|---|---|
| Global banner | Red/orange: “Emergency access active · 42:18 remaining” |
| Scope chip | ”IP policy edit only” or “Full Security admin” |
| Actions allowed | Explicit list—not full Owner by default |
| Extend session | Disabled or requires re-approval |
| End early | Prominent “End emergency session” |
| Auto-revoke | Hard logout + invalidate token at expiry |
EmergencySessionBanner
├── Icon: warning
├── Text: Emergency access · SSO bypass · Expires 3:42 PM
├── Scope: Can edit SSO settings · Cannot export org data
└── [ End session now ]
Pair countdown styling with session timeout patterns so engineers reuse timer components.
Dual approval queue
For high-risk scenarios, second approver reviews before elevation grants:
| Column | Spec |
|---|---|
| Requested | Timestamp + requester |
| Scenario | SSO bypass / IP override / etc. |
| Justification | Free text, min 20 chars |
| Requester verification | Passkey verified ✓ |
| Expires | Approve window countdown |
| Actions | Approve / Deny / Escalate to Owner |
DualApprovalCard
├── Requester: security-lead@acme.com (verified via passkey)
├── Scenario: SSO bypass — IdP certificate expired
├── Justification: "Okta cert rolled; 400 users locked out"
├── Window: Approve within 12:04
└── [ Approve elevation ] [ Deny ] [ Contact requester ]
Deny requires reason—logged to audit log. Escalate notifies Owner when approver unreachable.
Account recovery without org admin
Individual members locked out (lost 2FA, suspicious login) use a separate flow from org break-glass:
| Flow | Audience | Differs from break-glass |
|---|---|---|
| Self-service recovery | Any member | Email link + identity proof |
| Admin-initiated reset | Team admin | Resets member 2FA, not org policy |
| Org break-glass | Security Admin | Overrides org-wide policy |
Cross-link from suspicious login alerts and passkeys recovery screens. Do not label member recovery “break-glass”—reserve term for org-level emergency.
Audit and compliance requirements
Every break-glass event must emit structured audit rows:
| Event | Payload |
|---|---|
emergency.requested | requester, scenario, justification |
emergency.approved | approver, request id |
emergency.session.started | scope, expiry |
emergency.session.ended | reason: manual / timeout |
emergency.denied | approver, deny reason |
AuditLogRow
├── emergency.session.started
├── Actor: jane@acme.com · IP override · 1 hr scope
├── Approver: bob@acme.com
└── Immutable · Legal hold eligible
Surface break-glass usage in security posture dashboard as a risk signal when used more than twice per quarter.
Integration with related controls
| Control | Break-glass interaction |
|---|---|
| SSO enforce | Bypass allows password + step-up for eligible admins only |
| IP allowlist | Temporary rule edit or personal bypass token |
| DLP | Time-limited share exception with auto-expiry |
| Session timeout | Emergency session ignores extend; shorter idle timeout |
| Active sessions | Show “Emergency” badge on session row |
| SCIM | Break-glass does not disable provisioning—document separately |
Settings copy: “Emergency access does not disable audit logging or legal hold.”
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Break-glass hidden in docs only | Mass lockout during IdP outage | Login blocked screen link |
| Full Owner powers on elevation | Over-privileged incident response | Scope-limited sessions |
| No dual approval for SSO bypass | Single compromised admin owns org | Require second approver |
| Password-only verification | Defeats SSO security model | Passkey or backup codes |
| No cooldown | Repeated abuse | 24 hr per-user cooldown |
| Session with no visible countdown | Admin forgets to end | Persistent banner + auto-revoke |
| Member recovery labeled break-glass | Confusing audit and training | Separate flows and copy |
| No notification on use | Security team blind | Email DL on every session start |
| Approver same as requester | Dual control failure | Block self-approval |
| Audit events editable | Compliance failure | Immutable log + export |
Recommended workflow
- Define eligibility matrix in org Security → Emergency access with scenario checkboxes.
- Add login blocked entry points from IP and SSO failure screens.
- Build 4-step wizard: identify → verify → approve (if needed) → active session.
- Design time-boxed banner with scope chips and end-session action.
- Create dual approval queue for SSO bypass and full Security admin scope.
- Wire audit events and link to compliance export filters.
- Run tabletop test UI in Dev Mode with engineer annotations for token TTL.
FAQ
How is break-glass different from suspicious login recovery?
Break-glass is org-level—overrides SSO, IP, or DLP for designated admins. Suspicious login recovery is member-level account unlock after risk signals.
Can break-glass disable 2FA org-wide?
No—elevation uses step-up auth; it does not weaken standing MFA policy for other members.
Does break-glass work during SCIM provisioning errors?
Separate runbook—SCIM misconfig may need IdP fix; break-glass helps admins reach Security settings to pause SCIM or fix mappings.
Should break-glass appear in security posture score?
Yes as informational—unused break-glass is healthy; frequent use triggers review recommendation, not automatic penalty.
Tabletop test button—what does it simulate?
Dry-run wizard without granting real elevation—logs emergency.tabletop.completed for SOC2 evidence.
Next steps
- Design SSO and enterprise login UI in Figma — enforce SSO and rollback paths
- Design IP allowlist and network restrictions UI in Figma — login blocked and override context
- Design two-factor authentication and security settings UI in Figma — step-up verification methods
- Design audit log and security activity UI in Figma — immutable emergency event stream
- Design security posture dashboard and compliance checklist UI in Figma — break-glass usage signals
§ Keep reading