Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Recovering access during an identity-provider outage is possible only if an independent, tested emergency path already exists. First identify whether the failure is the identity provider itself, federation, multifactor delivery, a downstream access service, or a local configuration. Then use the preconfigured recovery method whose dependencies still work, record every action, and remove temporary access after normal sign-in is restored.
What to do first when sign-in fails
Do not immediately disable authentication controls or create new administrator accounts. A break-glass route may depend on a different component than the one that failed, and an improvised change can destroy auditability or lock out the remaining administrators.
- Declare and scope the incident. Record the start time, affected users, applications, regions and administrative functions. Determine whether the symptom is a complete sign-in failure, failed federation, unavailable multifactor delivery, a single application problem or an administrative lockout.
- Check authoritative status information. Consult the provider’s official service-status page and your own monitoring, identity logs, network telemetry and application health checks. If the status page is unreachable or reports no incident, continue troubleshooting rather than assuming the provider is healthy.
- Map the dependency chain. Identify the path from user and device to the identity provider, federation service, multifactor method, application or cloud access broker, privileged role and emergency authenticator. The recovery path must not rely on the failed link.
- Select a prepared route that matches the failure. Confirm its remaining dependencies, required roles, network reachability and authentication factor before asking responders to use it.
- Authorize a small responder group. Use the approved incident process and the least privilege needed for the task. Record who approved access, which account was used and what changes were made.
- Monitor and preserve evidence. Alert on emergency-account sign-ins, role changes, policy changes and credential changes. Save relevant identity, federation, application and administrative logs, including the incident timeline.
The central rule is simple: an emergency path must be independent of the component whose failure it is intended to survive. A fallback for an access-management service is not automatically a fallback for an outage of the external identity provider.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsBuild the recovery path before an outage
Emergency access cannot reliably be created after administrators lose control-plane access. AWS states that its emergency configuration should be deployed before a disruption because the required roles may be impossible to create during one. Apply the same principle to every identity architecture.
#1 Best Overall
- POWERFUL SECURITY KEY: The YubiKey 5C NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5C NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5C NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Design for independence
- Maintain at least two emergency administrator identities where the platform’s guidance calls for them, so one lost credential or unavailable person does not eliminate the only route.
- Use cloud-only or locally sourced credentials when federation could be unavailable. Do not make both emergency identities dependent on the same external directory, federation server or device-registration system.
- Use phishing-resistant authentication, such as a supported FIDO2 security key or certificate-based method, when the platform supports it. Enroll more than one approved factor where policy permits, and store recovery factors separately from the primary credentials.
- Ensure the emergency account can reach the service from an approved network during a perimeter, DNS or remote-access incident. An account that is independent of the IdP but reachable only through an unavailable corporate VPN is not an independent recovery path.
- Document the exact portal, tenant, role, factor, network route and approval required. Store the procedure and sealed credentials in a protected location that authorized responders can reach during an outage.
Protect emergency credentials as privileged assets
- Restrict knowledge of the credentials and maintain an explicit authorized-user list.
- Separate the password or private key from the recovery authenticator and from the instructions that reveal where each is stored.
- Configure high-priority alerts for every sign-in, failed sign-in, factor registration, password change, role assignment and policy change involving an emergency identity.
- Keep the accounts out of Conditional Access policies that would block their intended emergency use, while applying purposeful restrictions appropriate to the platform. Microsoft warns that an emergency account accidentally included in a blocking policy can be unusable when it is needed.
- Use permanent active administrator assignment only where the platform’s emergency-account guidance specifically requires it; do not copy a vendor’s settings into a different identity system without assessing its privilege model.
Test on a schedule
Testing must prove the whole path, not merely that a password is still valid. Validate sign-in, the enrolled factor, network reachability, required roles, alert generation and logging. Microsoft’s Entra checklist calls for validating emergency-account functionality at least every 90 days. Record the test result, correct drift immediately and avoid changing production data during the test.
Choose a route for the component that failed
| Recovery approach | Failure addressed | Dependency that remains | Important limits |
|---|---|---|---|
| Entra cloud-only emergency administrator accounts | Federated sign-in unavailable, certain MFA or device problems, or administrator lockout in Entra | Entra and the separately configured emergency authentication path | Requires secure credential and factor storage, deliberate Conditional Access scope, alerts and periodic tests |
| AWS IAM Identity Center direct federation | IAM Identity Center disruption | The external identity provider and AWS IAM data plane | Does not independently recover access when the external IdP is down; roles, trusts and emergency groups must exist in advance |
| Okta Disaster Recovery Admin app | Eligible regional infrastructure outage affecting supported products | Locally sourced Okta credentials and a supported factor | May be read-only during failover; product, attack, vendor, configuration and eligibility exclusions apply; failback may be customer initiated |
These are examples of different failure domains, not interchangeable recipes. Map your own topology and verify the current tenant documentation, product coverage and licensing before relying on any route.
Rank #2
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Microsoft Entra: when federated sign-in is unavailable
In a federated Entra environment, normal administrators may be unable to sign in when the external identity provider or its federation service is down. Microsoft recommends at least two emergency access accounts that are cloud-only and independent of federated providers.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Prepare the emergency accounts
- Create the accounts in the tenant rather than in the federated directory.
- Assign the permanent active Global Administrator role when following Microsoft’s emergency-account model; assess whether your own privilege policy requires a different arrangement.
- Use phishing-resistant authentication such as FIDO2 security keys or certificate-based authentication where supported. Keep the factor available to authorized responders and test it with the account.
- Exclude the emergency accounts from Conditional Access policies that would block their emergency sign-in, and document the reason for each exclusion.
- Store credentials and recovery factors securely, separate from ordinary administrator workstations.
- Enable high-priority monitoring for every sign-in and audit event involving these accounts.
Microsoft describes the intended use plainly: “Use emergency access accounts only for emergency or ‘break glass’ scenarios where normal administrative accounts can’t be used.” Treat that restriction as an operational control, not as a suggestion to use the accounts for routine work.
Rank #3
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Use the accounts during an incident
- Notify the responsible manager and security officers, then open or update the incident record.
- Review the incident-response playbook and confirm that the federated path, rather than the tenant itself, is the failing component.
- Sign in with the approved emergency account and its independently available factor.
- Make only the changes required to restore administration or service access. Capture timestamps, operators, commands and policy changes.
- Inspect sign-in and audit reports, allowing for reporting delay, and preserve logs needed for investigation.
- Open a provider support request when the incident meets your support or severity criteria.
Hybrid federation option
For a hybrid environment in which on-premises federation and AD FS are unavailable, Microsoft describes a conditional switch from federated authentication to managed authentication using password hash synchronization. This is an architecture-specific continuity measure, not a universal outage toggle. Confirm that synchronization, password policy, licensing, domain configuration and rollback procedures are ready before using it. Reverse the change when AD FS is available, and retain the relevant logs.
AWS IAM Identity Center: when the service is down but the external IdP works
AWS documents a different pattern. An emergency operations account and role design can provide direct IAM federation from the external identity provider into AWS, with roles in workload accounts. During normal operation, the emergency group may have no members. During an IAM Identity Center disruption, an authorized identity-provider administrator adds designated trusted users, who sign in to the still-available external IdP and assume the emergency roles.
Rank #4
- POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Required preparation
- Create the emergency IAM roles, trust relationships and permissions in advance.
- Build the direct-federation application in the external IdP and restrict who can enable or use it.
- Define the request and approval mechanism for adding users to emergency groups.
- Test access to the AWS IAM data plane and each required workload-account role.
- Document how to remove group membership and disable the direct-federation application after recovery.
This route works only when IAM Identity Center is unavailable while the external IdP and AWS IAM remain available. If the external IdP is the failed component, users cannot authenticate to the direct-federation application; use a separately designed IdP-independent route instead.
Free tools Windows power users keep installed
One-click scans. No signup required.
Failover and cleanup
- The identity-provider administrator enables the prepared direct-federation application.
- Process access requests through the existing authorization mechanism and add only designated users to the emergency groups.
- Responders assume the minimum emergency roles needed and record all actions.
- When IAM Identity Center health is confirmed, tell emergency users to sign out and return through the normal access portal.
- Disable the direct-federation application and remove all temporary emergency-group members.
- Review CloudTrail, identity-provider and incident records for unauthorized or unexpected activity.
Okta: regional disaster recovery and local credentials
Okta’s Standard Disaster Recovery covers certain infrastructure, storage or networking failures affecting core Okta products across regions and availability zones. Okta says failover usually takes one hour after it identifies a primary-region infrastructure outage. Its Enhanced Disaster Recovery documentation states a five-minute recovery-time objective for supported products. Both figures are vendor-published targets, not independent measurements or guarantees for every failure.
Best Value
- FIDO2 & Passkey Ready: Business-ready and FIDO2 L1 certified. This key is supported by major management suites and is ideal for both individual and enterprise deployment. Works seamlessly with Gmail, Facebook, GitHub, Dropbox, Coinbase, and more.
- Universal Connectivity (USB-A ): Features a built-in USB-A connector—simply unfold the key and plug it into your compatible PC or laptop for seamless authentication on the go.
- Dedicated Manager App: Use the Thetis Manager App for the initial hardware PIN setup. Setting the PIN on the device first ensures a smooth registration process. Once the PIN is configured, you can begin registering the key across your favorite FIDO2-compatible online services.
- Ultra-Durable & Portable: Featuring a rotating metal cover, this key is water, crush, and tamper-resistant. It fits easily on a keychain and requires no batteries or network connectivity.
- Check FIDO2 compatibility before purchase - Known limitations: ID Austria is not supported (requires FIDO2 Level 2). Windows Hello login only works with Windows Enterprise editions that support Entra ID, and NFC is NOT supported.
What administrators can expect
- During Standard Disaster Recovery, administrators may have read-only Admin Console access.
- Users may continue to access applications, while password resets are unavailable during failover.
- Enhanced Disaster Recovery is limited to eligible products; the documented exclusions include Okta Workflows, Okta Identity Governance and Auth0 Customer Identity Cloud.
- The Disaster Recovery Admin app requires locally sourced Okta credentials and a supported factor. It does not support authentication through an external identity provider.
- Self-service failover users must initiate failback after mitigation. Bookmark the recovery application if your organization is eligible, and verify current entitlement and factor requirements in the tenant documentation.
What this feature does not fix
Okta’s mechanism does not cover denial-of-service attacks, third-party vendor or application-connection failures, malicious data changes or configuration errors. A regional recovery feature therefore cannot substitute for configuration rollback, application troubleshooting or an independent administrator account.
How to use a FIDO2 security key safely
A hardware security key can make an emergency authentication path independent of a phone network, push-notification service or ordinary administrator device. It is not a recovery plan by itself. The identity platform must support the key, the emergency account must be enrolled, authorized responders must be able to retrieve it, and the complete sign-in and recovery procedure must be tested.
- Confirm the platform, tenant edition and authentication policy support the key and required protocol.
- Enroll the key to the emergency account before an incident, following the platform’s registration and recovery rules.
- Maintain an approved spare or alternate factor where policy allows, stored separately and protected against unauthorized use.
- Test from the network locations responders will use during an outage.
- Record custody, replacement and revocation procedures if a key is lost or suspected compromised.
Failback: return to normal without leaving a back door
Recovery is incomplete until ordinary sign-in is healthy and temporary access is removed. Confirm provider and downstream service health before changing the emergency configuration.
- Verify that the original identity, federation, MFA and access-management components are operating, not merely that a status page has changed.
- Communicate the transition time and instruct emergency users to end active sessions and return through the usual access portal.
- Disable temporary federation applications, remove emergency group memberships and revoke temporary grants.
- Restore planned federation, Conditional Access and policy settings, checking for accidental overwrites.
- Rotate credentials or replace factors if they were exposed, shared outside the approved group or used from an unexpected location.
- Preserve logs and the incident timeline, then conduct a review covering detection, authorization, usability, alerts, dependencies and cleanup.
- Update the runbook and retest any changed account, role, factor or network route.
Troubleshooting branches
The emergency account cannot sign in
- Check whether a Conditional Access policy, location rule, device requirement or authentication-strength policy blocks it.
- Verify that the account is cloud-only or locally sourced as intended, rather than silently dependent on the failed federation path.
- Confirm the factor is enrolled, available, not expired and supported by the current tenant configuration.
- Try the documented independent network route, not the same VPN, DNS path or device-management service that may be affected.
- Use the second emergency account and preserve failed-sign-in evidence for investigation.
The fallback portal opens but authorization fails
- Check that the required role, trust relationship or emergency-group membership was created before the outage.
- Confirm that the downstream data plane is healthy; an identity fallback cannot repair a separate cloud or application outage.
- Verify that the responder was approved and added to the correct group, then remove the membership after use.
The provider reports recovery but users still fail
- Check federation metadata, certificates, DNS, clock synchronization and network paths.
- Look for stale sessions or tokens and follow the platform’s documented sign-out and reauthentication process.
- Compare provider health with application and MFA-provider telemetry; the remaining failure may be outside the IdP.
Minimum contents of an emergency runbook
- Failure scenarios covered and scenarios explicitly not covered.
- Dependency diagram and status-page locations.
- Named approvers, responders and escalation contacts.
- Exact account names, portals, roles, factors and network routes, stored with appropriate secrecy.
- Step-by-step failover, monitoring and evidence-preservation instructions.
- Failback, credential-rotation and temporary-access-removal steps.
- Test frequency, last test result, known limitations and owner.
The most reliable answer to “What should we do if our identity provider is unavailable?” is therefore not a single emergency URL or account. It is a tested, independently authenticated route matched to the failed component, operated under an approved incident process and deliberately dismantled when normal access returns.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
