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

ScenarioTypical triggerEntry point
SSO IdP outageEnforce SSO on; IdP unreachableLogin page → “Emergency admin access”
IP allowlist lockoutAdmin travels; VPN downLogin blocked screen
MFA device lossOwner locked out of 2FASecurity settings recovery
Mass account lockoutBrute-force policy misfireOrg Security → Emergency access
DLP false positiveCritical share blocked mid-incidentDLP 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

ColumnSpecNotes
RoleOwner, Security Admin onlyMax 3 eligible accounts
ScenarioSSO bypass, IP override, DLP exceptionCheckbox per scenario
Max session15 min – 4 hrDefault 1 hr
Dual approvalRequired / Optional / OffOn for SSO bypass
CooldownMin hours between usesDefault 24 hr per user
NotifyEmail Security distribution listCannot disable
Audit retentionImmutable, 7 yrLink 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 elementSpec
Global bannerRed/orange: “Emergency access active · 42:18 remaining”
Scope chip”IP policy edit only” or “Full Security admin”
Actions allowedExplicit list—not full Owner by default
Extend sessionDisabled or requires re-approval
End earlyProminent “End emergency session”
Auto-revokeHard 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:

ColumnSpec
RequestedTimestamp + requester
ScenarioSSO bypass / IP override / etc.
JustificationFree text, min 20 chars
Requester verificationPasskey verified ✓
ExpiresApprove window countdown
ActionsApprove / 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:

FlowAudienceDiffers from break-glass
Self-service recoveryAny memberEmail link + identity proof
Admin-initiated resetTeam adminResets member 2FA, not org policy
Org break-glassSecurity AdminOverrides 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:

EventPayload
emergency.requestedrequester, scenario, justification
emergency.approvedapprover, request id
emergency.session.startedscope, expiry
emergency.session.endedreason: manual / timeout
emergency.deniedapprover, 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.


ControlBreak-glass interaction
SSO enforceBypass allows password + step-up for eligible admins only
IP allowlistTemporary rule edit or personal bypass token
DLPTime-limited share exception with auto-expiry
Session timeoutEmergency session ignores extend; shorter idle timeout
Active sessionsShow “Emergency” badge on session row
SCIMBreak-glass does not disable provisioning—document separately

Settings copy: “Emergency access does not disable audit logging or legal hold.”


Common mistakes

MistakeWhy it hurtsFix
Break-glass hidden in docs onlyMass lockout during IdP outageLogin blocked screen link
Full Owner powers on elevationOver-privileged incident responseScope-limited sessions
No dual approval for SSO bypassSingle compromised admin owns orgRequire second approver
Password-only verificationDefeats SSO security modelPasskey or backup codes
No cooldownRepeated abuse24 hr per-user cooldown
Session with no visible countdownAdmin forgets to endPersistent banner + auto-revoke
Member recovery labeled break-glassConfusing audit and trainingSeparate flows and copy
No notification on useSecurity team blindEmail DL on every session start
Approver same as requesterDual control failureBlock self-approval
Audit events editableCompliance failureImmutable log + export

  1. Define eligibility matrix in org Security → Emergency access with scenario checkboxes.
  2. Add login blocked entry points from IP and SSO failure screens.
  3. Build 4-step wizard: identify → verify → approve (if needed) → active session.
  4. Design time-boxed banner with scope chips and end-session action.
  5. Create dual approval queue for SSO bypass and full Security admin scope.
  6. Wire audit events and link to compliance export filters.
  7. 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

Share on X

§ Keep reading

Related guides.