Emergency Access

Emergency access procedures restore authentication capabilities when normal identity systems are unavailable. This playbook covers break-glass account activation, temporary access whitelisting, and identity provider failover scenarios. Execute these procedures when staff cannot authenticate through standard channels and business operations require immediate access restoration.

Activation criteria

Invoke this playbook when any of the following conditions exist:

Do not invoke this playbook for individual user access issues, forgotten passwords, or locked accounts that standard support procedures can resolve within acceptable timeframes.

Roles

The access controller and technical operator must be different individuals. This separation prevents single-person credential access and maintains audit integrity. In organisations with single IT staff, the backup access controller must be a non-IT manager with secure access to break-glass credential storage.

Emergency access decision framework

Before executing procedures, determine which access restoration method applies to your situation:

                            +---------------------------+
                            |   Authentication          |
                            |   Failure Detected        |
                            +-------------+-------------+
                                          |
                            +-------------v-------------+
                            |   Is IdP completely       |
                            |   unavailable?            |
                            +-------------+-------------+
                                          |
                    +---------------------+---------------------+
                    |                                           |
                    | Yes                                       | No
                    v                                           v
          +-----------------+                     +-------------+-------------+
          | BREAK-GLASS     |                     |   Is MFA system           |
          | ACCOUNTS        |                     |   unavailable?            |
          | (Phase 2A)      |                     +-------------+-------------+
          +-----------------+                                   |
                                          +---------------------+---------------------+
                                          |                                           |
                                          | Yes                                       | No
                                          v                                           v
                              +-----------------------+                      +-----------------+
                              | MFA BYPASS            |                      | CONDITIONAL     |
                              | CONFIGURATION         |                      | ACCESS          |
                              | (Phase 2B)            |                      | ADJUSTMENT      |
                              +-----------------------+                      | (Phase 2C)      |
                                                                             +-----------------+

Figure 1: Emergency access method selection based on failure type

The decision between methods depends on which authentication component has failed. Identity provider failures require break-glass accounts because no user authentication is possible. MFA-only failures allow normal username and password authentication with temporary MFA bypass. Partial failures or access restrictions use conditional access policy adjustments.

Phase 1: Immediate assessment

Objective: Confirm authentication failure scope and determine appropriate response Timeframe: 5 to 15 minutes

1. Verify the authentication failure affects multiple users, not a single account issue.

   Test authentication from at least two different user accounts on two different networks. If only one user or one network is affected, this is not an emergency access scenario.

   # Test IdP availability from command line
   curl -I https://login.example.org/oauth2/authorize
   # Expected: HTTP 200 or 302
   # Failure: Connection timeout, 500, 502, 503

2. Check identity provider status through vendor status pages and monitoring systems.

   Provider	Status page
   Microsoft Entra ID	status.azure.com
   Okta	status.okta.com
   Google Workspace	workspace.google.com/status
   Keycloak (self-hosted)	Internal monitoring dashboard

   Record the status page information including incident ID if a known outage exists.

3. Determine which authentication components are affected.

   Test each component independently:

   Component	Test method	Pass criteria
   IdP login page	Load login URL in browser	Page renders within 5 seconds
   Username/password authentication	Attempt login with known credentials	Authentication accepted or rejected (not timeout)
   MFA push delivery	Trigger MFA prompt	Notification received within 30 seconds
   MFA TOTP	Enter TOTP code	Code accepted or rejected (not timeout)
   Session token validation	Access protected application	Application loads or denies (not authentication redirect loop)

4. Identify the user population requiring access restoration.

   Categorise by urgency:

   Category	Definition	Example
   Critical	Cannot perform essential functions without access	Finance staff during payroll processing
   High	Significant operational impact within 2 hours	Programme staff with beneficiary appointments
   Standard	Can work on alternative tasks temporarily	Most staff during general business

5. Contact the access controller to report findings and request authorisation.

   Provide: failure scope, affected components, estimated user impact, recommended response method.

Decision point: If authentication failure is confirmed as widespread and affecting critical operations, proceed to Phase 2. If failure is limited or resolving, continue monitoring and prepare for Phase 2 if degradation continues.

Checkpoint: Assessment documented, access controller notified, response method selected.

Phase 2A: Break-glass account activation

Objective: Restore administrative access using pre-provisioned emergency accounts Timeframe: 10 to 20 minutes

Break-glass accounts are pre-created administrative accounts with credentials stored securely offline. These accounts bypass the primary identity provider entirely, authenticating directly against directory services or application-local accounts.

1. Retrieve break-glass credentials from secure storage.

   Physical storage locations (retrieve from primary; use secondary only if primary inaccessible):

   Location	Contents	Access requirements
   Primary: Office safe	Sealed envelope with account credentials	Access controller + safe combination
   Secondary: Bank safety deposit	Duplicate sealed envelope	Access controller + bank verification
   Tertiary: Escrow with legal counsel	Encrypted USB with credentials	Board authorisation + legal release

   The sealed envelope contains:

   • Break-glass account username (typically bg-admin-01@example.org)
   • Initial password (complex, 20+ characters)
   • TOTP seed for hardware token or recovery codes
   • List of systems accessible with this account

2. Verify envelope seal integrity before opening.

   If seal is broken or tampered with, do not use credentials. Report to security team and escalate to secondary storage location.

3. Activate the break-glass account in identity systems.

   For Microsoft Entra ID:

   # Connect using break-glass account credentials
   Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.AccessAsUser.All"

   # Enable the account (if disabled as dormant protection)
   Update-MgUser -UserId "bg-admin-01@example.org" -AccountEnabled:$true

   # Verify account status
   Get-MgUser -UserId "bg-admin-01@example.org" | Select DisplayName, AccountEnabled

For Keycloak:

   # Authenticate with break-glass credentials
   /opt/keycloak/bin/kcadm.sh config credentials \
     --server https://auth.example.org \
     --realm master \
     --user bg-admin-01 \
     --password 'retrieved-password'

   # Verify authentication succeeded
   /opt/keycloak/bin/kcadm.sh get serverinfo

4. Document the activation with timestamp and authorising personnel.

   Record in the incident log:

   BREAK-GLASS ACTIVATION
   Timestamp: 2024-11-16T14:32:00Z
   Account: bg-admin-01@example.org
   Activated by: [Technical operator name]
   Authorised by: [Access controller name]
   Reason: IdP service outage - vendor incident INC-847291
   Witness: [Verification officer name]

5. Change the break-glass account password immediately after first login.

   Generate a new password meeting complexity requirements (20+ characters, mixed case, numbers, symbols). Do not record this password. You will reset it again during deactivation.

6. Proceed to restore access for affected users using the break-glass account.

Checkpoint: Break-glass account active, password changed, activation documented with authorisation chain.

Phase 2B: MFA bypass configuration

Objective: Allow authentication without MFA when MFA systems are unavailable Timeframe: 15 to 30 minutes

MFA bypass temporarily allows users to authenticate with only username and password. This significantly reduces security posture and must be time-limited and logged.

1. Configure temporary MFA bypass with automatic expiry.

   For Microsoft Entra ID conditional access:

   # Create temporary CA policy to bypass MFA for specific group
   $params = @{
     displayName = "EMERGENCY: Temporary MFA Bypass - Delete by [datetime]"
     state = "enabled"
     conditions = @{
       users = @{
         includeGroups = @("[emergency-access-group-id]")
       }
       applications = @{
         includeApplications = @("All")
       }
     }
     grantControls = @{
       operator = "OR"
       builtInControls = @("block")  # Will override with password-only
     }
   }

   # Note: Actual implementation requires excluding MFA requirement
   # from grant controls for the emergency group

For Okta:

   # Create authentication policy rule with MFA bypass
   curl -X POST https://example.okta.com/api/v1/policies/{policyId}/rules \
     -H "Authorization: SSWS {api-token}" \
     -H "Content-Type: application/json" \
     -d '{
       "name": "EMERGENCY: MFA Bypass - Expires 2024-11-16T18:00:00Z",
       "priority": 1,
       "conditions": {
         "people": {
           "groups": {
             "include": ["emergency-access-group-id"]
           }
         }
       },
       "actions": {
         "signon": {
           "access": "ALLOW",
           "requireFactor": false
         }
       }
     }'

2. Add affected users to the emergency access group.

   Add users in priority order (critical first), documenting each addition:

   # Add user to emergency access group
   Add-MgGroupMember -GroupId "[emergency-group-id]" -DirectoryObjectId "[user-id]"

   # Verify membership
   Get-MgGroupMember -GroupId "[emergency-group-id]" | Select Id, DisplayName

3. Notify users that MFA bypass is active.

   Send communication including:

   • Confirmation they can now authenticate with password only
   • Reminder to use strong, unique password
   • Warning to be vigilant for phishing during this period
   • Expected duration of bypass

4. Enable enhanced monitoring for password-only authentications.

   Configure alerts for:

   • Authentication from unusual locations
   • Multiple failed password attempts
   • Successful authentication followed by unusual activity
   • Any authentication outside business hours

5. Set calendar reminder for bypass expiry verification.

   Schedule verification at bypass end time to confirm automatic deactivation occurred.

Checkpoint: MFA bypass active for designated users, monitoring enhanced, automatic expiry configured, users notified.

Phase 2C: Conditional access adjustment

Objective: Modify access policies to work around partial authentication failures Timeframe: 15 to 30 minutes

Conditional access adjustments address scenarios where authentication partially functions but specific conditions block legitimate access. Common scenarios include geographic restrictions blocking travelling staff, device compliance checks failing due to service issues, or network-based policies blocking legitimate access points.

1. Identify the specific conditional access policy blocking legitimate access.

   Review sign-in logs for blocked authentication attempts:

   # Get recent failed sign-ins with CA policy information
   Get-MgAuditLogSignIn -Filter "status/errorCode ne 0" -Top 50 |
     Select UserPrincipalName, Status, ConditionalAccessStatus,
            AppliedConditionalAccessPolicies |
     Format-Table

The AppliedConditionalAccessPolicies field identifies which policies caused the block.

2. Create a temporary exception policy with higher priority.

   Exception policies must:

   • Have higher priority than blocking policy (lower number)
   • Target only specific affected users or groups
   • Include compensating controls where possible
   • Have explicit expiry or deletion date in name

   # Example: Allow access from specific IP during emergency
   $exceptionParams = @{
     displayName = "EMERGENCY: Allow [location] access - Delete 2024-11-17"
     state = "enabled"
     conditions = @{
       users = @{
         includeUsers = @("[affected-user-ids]")
       }
       locations = @{
         includeLocations = @("[emergency-location-id]")
       }
     }
     grantControls = @{
       operator = "OR"
       builtInControls = @("mfa")  # Still require MFA as compensating control
     }
   }

3. Document the policy exception with business justification.

   Record:

   • Original blocking policy name and ID
   • Exception policy configuration
   • Business reason for exception
   • Users affected
   • Compensating controls in place
   • Scheduled removal date

4. Test access restoration with one affected user before broader rollout.

5. Monitor for policy conflicts or unexpected access grants.

Checkpoint: Exception policy active, documented, tested, monitoring in place.

Phase 3: User access restoration

Objective: Restore access for affected users using the emergency access method Timeframe: 30 minutes to 2 hours depending on user count

+----------------------------------------------------------------+
|                 USER ACCESS RESTORATION FLOW                   |
+----------------------------------------------------------------+
|                                                                |
|       +------------------+                                     |
|       | User Requests    |                                     |
|       | Emergency Access +----+                                |
|       +------------------+    |                                |
|                               v                                |
|                       +-------+--------+                       |
|                       | Verify User    |                       |
|                       | Identity       |                       |
|                       | (verification  |                       |
|                       |  officer)      |                       |
|                       +-------+--------+                       |
|                               |                                |
|                  +------------+-------------+                  |
|                  |                          |                  |
|                  | Verified                 | Not verified     |
|                  v                          v                  |
|          +--------+--------+        +-------+--------+         |
|          | Add to          |        | Escalate to    |         |
|          | Emergency       |        | Access         |         |
|          | Access Group    |        | Controller     |         |
|          +--------+--------+        +----------------+         |
|                   |                                            |
|                   v                                            |
|          +--------+--------+                                   |
|          | User Tests      |                                   |
|          | Access          |                                   |
|          +--------+--------+                                   |
|                   |                                            |
|         +---------+---------+                                  |
|         |                   |                                  |
|         | Success           | Failure                          |
|         v                   v                                  |
|     +---+-------+    +------+------+                           |
|     | Document  |    | Troubleshoot|                           |
|     | & Close   |    | Individual  |                           |
|     +-----------+    | Issue       |                           |
|                      +-------------+                           |
|                                                                |
+----------------------------------------------------------------+

Figure 2: User access restoration workflow with verification requirements

1. Establish a request intake channel for users needing emergency access.

   Options by organisation size:

   Organisation size	Primary channel	Backup channel
   Under 50 users	Direct phone to IT	Email alias
   50 to 200 users	Shared phone line with queue	Teams/Slack channel
   Over 200 users	Temporary web form	Phone queue with callback

2. Verify each user’s identity before granting emergency access.

   Identity verification must use out-of-band confirmation. Never verify identity using only the channel through which the request arrived.

   Acceptable verification methods:

   Method	Verification strength	Use when
   Video call with known manager present	High	High-privilege access requests
   Phone callback to HR-listed number	Medium	Standard access requests
   Security questions + manager confirmation	Medium	When video/phone unavailable
   Physical presence with ID	Highest	User can reach office

3. Add verified users to the emergency access group or issue temporary credentials.

   For break-glass scenarios where users need temporary local accounts:

   # Create temporary local admin account (Linux)
   sudo useradd -m -G sudo -s /bin/bash temp-[username]
   sudo passwd temp-[username]
   # Set password expiry for 24 hours
   sudo chage -E $(date -d "+1 day" +%Y-%m-%d) temp-[username]

   # Create temporary local admin account (Windows)
   $securePassword = Read-Host -AsSecureString "Enter temporary password"
   New-LocalUser -Name "temp-$username" -Password $securePassword `
     -AccountExpires (Get-Date).AddDays(1)
   Add-LocalGroupMember -Group "Administrators" -Member "temp-$username"

4. Confirm access restoration with each user.

   User must successfully authenticate and access their required applications before closing their request.

5. Document each access grant with verification details.

   Log entry format:

   EMERGENCY ACCESS GRANT
   Timestamp: 2024-11-16T15:47:00Z
   User: j.smith@example.org
   Verified by: [Verification officer] via video call with manager present
   Access method: Added to emergency-mfa-bypass group
   Applications confirmed: Email, SharePoint, Finance system
   Expected duration: Until IdP restored

Checkpoint: All critical users have confirmed access, access grants documented with verification chain.

Phase 4: Monitoring and maintenance

Objective: Maintain security visibility during emergency access period Timeframe: Continuous until normal access restored

During emergency access periods, reduced authentication controls require compensating monitoring. The attack surface increases when MFA is bypassed or when users authenticate through non-standard paths.

1. Enable enhanced authentication logging.

   Increase log retention and detail level for authentication events:

   # Example: Increase audit logging verbosity (Linux PAM)
   # In /etc/pam.d/common-auth, ensure:
   auth required pam_tally2.so deny=5 unlock_time=900 audit

   # Verify audit daemon is capturing auth events
   ausearch -m USER_AUTH -ts today | tail -20

2. Configure real-time alerts for suspicious authentication patterns.

   Alert triggers during emergency access:

   Pattern	Alert threshold	Response
   Failed password attempts	3 failures in 5 minutes	Investigate immediately
   Successful auth from new location	Any new country	Verify with user
   Auth outside business hours	Any during bypass	Verify with user
   Multiple accounts from same IP	3+ accounts	Block IP, investigate
   Password change attempts	Any during emergency	Require verification officer approval

3. Review authentication logs every 2 hours during active emergency.

   Sample review query (Microsoft Entra ID):

   # Get authentications during emergency period
   $startTime = "2024-11-16T14:00:00Z"
   Get-MgAuditLogSignIn -Filter "createdDateTime ge $startTime" |
     Where-Object { $_.ConditionalAccessStatus -ne 'success' } |
     Select UserPrincipalName, AppDisplayName, IPAddress, Location, Status

4. Maintain communication with users about expected emergency duration.

   Update users every 4 hours with:

   • Current status of normal authentication systems
   • Expected restoration time (if known)
   • Any changes to emergency procedures
   • Reminder of security precautions

5. Coordinate with identity provider vendor on restoration timeline.

   For vendor-managed IdP outages, establish direct communication channel with vendor support. Request:

   • Root cause information
   • Estimated restoration time
   • Notification when service restored
   • Post-incident report timeline

Checkpoint: Monitoring active, alerts configured, review schedule established, vendor communication in progress.

Phase 5: Access restoration and deactivation

Objective: Return to normal authentication and deactivate emergency access Timeframe: 30 minutes to 2 hours

1. Verify normal authentication is restored.

   Test authentication through normal channels with users from each affected category:

   Test case	User type	Applications to test
   Standard MFA	Regular staff	Email, collaboration
   Location-based access	Remote/travelling staff	VPN, cloud applications
   Device compliance	Managed device users	All applications
   Privileged access	IT administrators	Admin consoles

2. Notify users that normal authentication is restored.

   Communication template:

   Subject: Normal authentication restored - Action required

   Authentication services have been restored. Please:

   1. Sign out of all sessions
   2. Sign in using your normal credentials and MFA
   3. Report any issues to [contact] immediately

   Emergency access will be deactivated at [time]. After this time,
   emergency credentials and bypass configurations will no longer work.

3. Remove users from emergency access groups.

   # Remove all members from emergency group
   $groupId = "[emergency-group-id]"
   $members = Get-MgGroupMember -GroupId $groupId
   foreach ($member in $members) {
     Remove-MgGroupMemberByRef -GroupId $groupId -DirectoryObjectId $member.Id
   }

   # Verify group is empty
   Get-MgGroupMember -GroupId $groupId | Measure-Object

4. Deactivate break-glass accounts.

   # Disable break-glass account
   Update-MgUser -UserId "bg-admin-01@example.org" -AccountEnabled:$false

   # Reset password to new unknown value (prevents reuse)
   $newPassword = [System.Web.Security.Membership]::GeneratePassword(24, 4)
   # Password is not recorded - account requires re-provisioning for next use

5. Delete temporary bypass policies and exception rules.

   # Remove emergency CA policy
   Remove-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "[policy-id]"

   # Verify policy removed
   Get-MgIdentityConditionalAccessPolicy | Where DisplayName -like "*EMERGENCY*"

6. Delete temporary local accounts.

   # Remove temporary Linux accounts
   sudo userdel -r temp-jsmith

   # Verify removal
   grep "temp-" /etc/passwd

   # Remove temporary Windows accounts
   Remove-LocalUser -Name "temp-jsmith"

   # Verify removal
   Get-LocalUser | Where Name -like "temp-*"

7. Document deactivation with timestamps.

   EMERGENCY ACCESS DEACTIVATION
   Timestamp: 2024-11-16T19:45:00Z
   Deactivated by: [Technical operator]
   Authorised by: [Access controller]

   Actions completed:
   - Emergency access group emptied (47 users removed)
   - Break-glass account bg-admin-01 disabled and password reset
   - CA policy "EMERGENCY: MFA Bypass" deleted
   - 3 temporary local accounts deleted

   Normal authentication verified working: Yes
   Users notified: Yes, at 19:30

Checkpoint: All emergency access mechanisms deactivated, normal authentication confirmed, deactivation documented.

Phase 6: Post-emergency review

Objective: Document incident, rotate credentials, identify improvements Timeframe: Within 48 hours of restoration

+--------------------------------------------------------------------+
|                  POST-EMERGENCY REVIEW CHECKLIST                   |
+--------------------------------------------------------------------+
|                                                                    |
|   CREDENTIAL ROTATION                          STATUS              |
|   +----------------------------------------+  +------------------+ |
|   | Break-glass account password           |  |    [  ] Done     | |
|   | Break-glass TOTP seed                  |  |    [  ] Done     | |
|   | Sealed envelope replacement            |  |    [  ] Done     | |
|   | Secondary storage update               |  |    [  ] Done     | |
|   +----------------------------------------+  +------------------+ |
|                                                                    |
|   DOCUMENTATION                                                    |
|   +----------------------------------------+  +------------------+ |
|   | Incident timeline                      |  |    [  ] Done     | |
|   | Access grants log                      |  |    [  ] Done     | |
|   | Authentication logs preserved          |  |    [  ] Done     | |
|   | Lessons learned documented             |  |    [  ] Done     | |
|   +----------------------------------------+  +------------------+ |
|                                                                    |
|   VERIFICATION                                                     |
|   +----------------------------------------+  +------------------+ |
|   | All temp accounts deleted              |  |    [  ] Done     | |
|   | All bypass policies removed            |  |    [  ] Done     | |
|   | Emergency group empty                  |  |    [  ] Done     | |
|   | Normal access working                  |  |    [  ] Done     | |
|   +----------------------------------------+  +------------------+ |
|                                                                    |
+--------------------------------------------------------------------+

Figure 3: Post-emergency review completion checklist

1. Rotate all break-glass credentials.

   Break-glass credentials must be rotated after every use, even if compromise is not suspected. The credentials were exposed outside secure storage and handled by multiple personnel.

   Generate new credentials:

   • New password: minimum 24 characters, cryptographically random
   • New TOTP seed: fresh seed from authenticator app or hardware token
   • New recovery codes: generate fresh set, destroy old codes

   Secure new credentials:

   • Print password on paper (do not store electronically)
   • Place in new tamper-evident envelope
   • Sign and date envelope seal
   • Update primary secure storage
   • Update secondary storage within 7 days

2. Review all authentication logs from the emergency period.

   Export logs for the full emergency period plus 24 hours before and after:

   # Export sign-in logs for review
   $startDate = "2024-11-15T14:00:00Z"  # 24h before emergency
   $endDate = "2024-11-17T20:00:00Z"    # 24h after restoration

   Get-MgAuditLogSignIn -Filter "createdDateTime ge $startDate and createdDateTime le $endDate" |
     Export-Csv -Path "emergency-period-signins.csv"

Review for:

• Any authentications not attributable to known users
• Authentication patterns inconsistent with user behaviour
• Access to sensitive applications during emergency period
• Any evidence of credential misuse

3. Document the complete incident timeline.

   Include:

   • Initial detection time and method
   • Each decision point and who made the decision
   • Each action taken with timestamp and personnel
   • Restoration confirmation time
   • Total duration of emergency access period
   • Number of users granted emergency access
   • Any security events during emergency period

4. Conduct lessons learned session.

   Within 5 business days, convene all participants to discuss:

   • What triggered the emergency?
   • How quickly was the emergency detected?
   • Were break-glass credentials accessible and valid?
   • Did emergency procedures work as documented?
   • What slowed down response?
   • What should change for next time?

5. Update emergency access procedures based on lessons learned.

   Common improvements include:

   • Additional break-glass accounts for specific applications
   • Faster identity verification methods
   • Pre-staged communication templates
   • Additional monitoring during emergency periods
   • Cross-training for backup personnel

Checkpoint: Credentials rotated, logs reviewed, incident documented, improvements identified.

Communications

Communication templates

Executive notification (30 minutes):

Subject: [URGENT] Authentication emergency - Break-glass activated

We have activated emergency access procedures due to [IdP outage / MFA failure].

Current status: Phase [X] - [description]
Users affected: Approximately [number]
Business impact: [Critical systems affected]
Expected duration: [estimate or "investigating"]

Actions taken:
- Break-glass account activated at [time]
- [Number] users granted emergency access
- Enhanced monitoring active

Next update: [time]
Contact: [Access controller name and phone]

User notification (1 hour):

Subject: Authentication service disruption - Alternative access available

We are experiencing issues with our normal login system. If you cannot
sign in normally, emergency access is available.

To request emergency access:
1. Contact IT at [phone/channel]
2. Be prepared to verify your identity
3. You will receive temporary access credentials

Expected resolution: [time estimate]

Please be extra vigilant for phishing attempts during this period.
Do not share any temporary credentials you receive.

Updates will be posted to [location].

Restoration notification:

Subject: Normal authentication restored - Please sign in normally

Authentication services have been restored. Please:

1. Sign out of all current sessions
2. Close your browser completely
3. Sign in again using your normal credentials and MFA

If you were using emergency access, those credentials will stop
working at [time].

Report any problems to [contact].

Thank you for your patience during the disruption.

Offline access scenarios

When both cloud identity systems and network connectivity are unavailable, local cached credentials provide limited access to devices and locally installed applications.

Windows cached credentials: Domain-joined Windows devices cache credentials for the last 10 interactive logins by default. Users can authenticate to their device and access locally stored files without network connectivity. This cache persists across reboots.

Verify cached credential policy:

# Check cached logon count (default 10)
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" `
  -Name CachedLogonsCount

macOS cached credentials: Mobile accounts cache passwords locally. Authentication works offline but cannot access network resources.

Application-specific offline: Some applications maintain local credential caches:

Limitations of offline access:

• Cannot access network file shares
• Cannot access cloud applications
• Cannot send or receive new email
• Cannot join new Teams meetings
• Cannot authenticate to new applications
• Any password changes made offline will conflict on reconnection

For extended offline scenarios (disaster affecting connectivity for days), consider:

• Pre-positioned local file server with essential documents
• Offline-capable applications for critical functions
• Documented procedures for operating without network access
• Regular testing of offline work capability

See also

• Break-Glass Access for concepts and pre-provisioning requirements
• Identity and Access Management for IAM architecture
• Multi-Factor Authentication for MFA concepts
• DR Site Invocation for full DR activation
• Major Service Outage for service outage response
• Incident Management for incident process integration