Your identity provider (IdP) is the front door to almost every business system you run, so it deserves more hardening than any single application behind it. To protect it against account takeover, focus on a short list: hardware-backed MFA for administrators, conditional access tied to device trust, no legacy authentication, sensible session and token lifetimes, as few admin roles as possible, tested break-glass accounts, alerting on risky sign-ins and admin changes, and a verified process for MFA resets. Then protect the IdP's own admin console and API tokens, which are often overlooked.

Why the identity provider is the priority

Single sign-on concentrates access. One set of credentials unlocks email, file storage, finance tools, source code and cloud consoles. That's a big usability and security win, but it also means a single compromised IdP account can reach everything that account is entitled to.

Admin accounts matter even more. Someone with IdP admin rights can create users, reset MFA, change sign-in policies and add new federation trusts. With those powers, one stolen admin credential can quietly become persistent access to the whole organization.

Account takeover usually starts with something ordinary: a reused password, a credential-stuffing run against an internet-facing login, a session token lifted from an infected laptop, or a recovery process that hands out access too easily. Each section below closes one of those paths.

Require strong MFA, starting with admins

MFA is table stakes, but not all MFA is equal. SMS and voice codes travel over a phone network you don't control. One-time codes from an authenticator app are better, but they're still a secret the user types, so anything that captures keystrokes can capture them too. Push approvals that need only a tap tend to get accepted out of habit.

For administrators, require FIDO2 security keys or device-bound passkeys. These are bound to the IdP's domain and sign a fresh challenge at every sign-in, so there's no code that can be captured and reused. Issue two keys per admin so a lost key doesn't become an emergency.

For everyone else, move toward passkeys or FIDO2 where you can, and use app-based methods with number matching in the meantime. Then turn off SMS and voice for any group that no longer needs them. A strong method doesn't help much if a weaker one is still allowed on the same account.

Use conditional access and device trust

Conditional access lets the IdP decide whether to allow a sign-in based on context: who the user is, what they're accessing, where they're signing in from and what device they're using. Good baseline policies include:

  • Require MFA for all users and all applications, with no broad exclusions.
  • Require a managed, compliant device for admin portals and sensitive applications. Device trust is usually established through your device management platform or a device certificate.
  • Restrict unmanaged devices to browser-only access with downloads blocked, or block them entirely for high-risk apps.
  • Block sign-ins from countries you don't operate in, while remembering that location is a weak signal on its own.
  • Step up authentication when the IdP flags a sign-in as risky, and block it outright at the highest risk levels.

Build policies in report-only or audit mode first, if your IdP supports it. Review what would have been blocked, fix the gaps, then enforce.

Disable legacy authentication protocols

Older protocols such as IMAP, POP3, SMTP AUTH and basic authentication over HTTP send a username and password with every request. They can't perform modern MFA and they often bypass conditional access. That makes them a favorite target for password spraying and credential stuffing, because a correct password is all it takes.

Find out which legacy protocols are still in use by checking your sign-in logs for them. You'll usually find a few printers, scanners, old scripts or line-of-business apps. Move those to modern authentication or a tightly scoped service account, then block legacy protocols at the IdP and in each application that still accepts them.

Protect sessions and tokens

MFA protects the moment of sign-in. After that, the user holds session cookies and tokens, and anyone who copies them can often act as that user without a password or a second factor. Session token theft from compromised endpoints is a common way around strong authentication.

Controls to put in place:

  • Shorten session lifetimes for privileged access. Admin portals should ask for re-authentication after a few hours, not weeks.
  • Review token lifetimes. Keep access tokens short-lived and set limits on refresh tokens, especially for high-risk applications.
  • Revoke sessions on important events. A password reset, a disabled account, removal of an MFA method or a high-risk sign-in should end every active session and refresh token for that user.
  • Bind tokens where you can. Some platforms can tie tokens to a device or a client key. On the standards side, mutual-TLS certificate-bound tokens (RFC 8705) and OAuth 2.0 Demonstrating Proof of Possession, or DPoP (RFC 9449, published September 2023), make stolen tokens much harder to reuse.

Minimize admin roles

Every standing admin account is a target. Reduce the number and the scope:

  • Use separate admin accounts. Administrators should sign in to their daily work with a normal account and use a dedicated admin identity only for admin tasks. Admin accounts shouldn't have email or browse the web.
  • Keep top-level admins to a handful. Most IdPs have a super-admin or global-admin role. Two to four people is plenty for most small and mid-sized organizations.
  • Use scoped roles. Help desk staff need password and MFA reset rights for standard users, not for other admins. User administrators don't need to edit sign-in policies.
  • Grant elevation just in time. Where your IdP supports it, make admin roles eligible rather than permanent, require approval or a justification to activate them, and let them expire.
  • Review role assignments quarterly and remove anything nobody can justify.

Set up and test break-glass accounts

Break-glass (emergency access) accounts let you get back into the IdP if MFA fails, a federation dependency breaks or a conditional access policy locks everyone out. They are also highly privileged accounts that nobody signs in to day to day, so they need careful handling.

A sound break-glass setup:

  1. Create two accounts, cloud-only, not synced or federated from another directory.
  2. Protect each with a long random password and a dedicated FIDO2 security key, stored separately and physically secured.
  3. Exclude them from conditional access policies that could lock you out, but don't leave them without strong authentication.
  4. Alert on every sign-in to either account, immediately and to more than one person.
  5. Test them on a schedule, such as quarterly, and after major policy changes. Record who tested and when.

Log and alert on risky sign-ins and admin changes

Your IdP's logs are only useful if someone sees the important events in time. Forward sign-in and audit logs to your central logging platform and keep them long enough to investigate, since many IdPs retain them for only a short period by default.

Alert on at least these:

  • Sign-ins to break-glass accounts
  • New admin role assignments and changes to existing ones
  • Changes to conditional access or sign-in policies
  • New federation trusts, identity sources or changes to signing certificates
  • MFA method registrations, removals and admin-initiated MFA resets
  • Creation of new API tokens, service accounts or application credentials
  • Sign-ins flagged as high risk, and attempts using legacy protocols
  • Bulk user changes or bulk session revocations

Each alert needs an owner and a documented first response. An alert that goes to a shared inbox nobody reads offers no protection.

Verify identity for MFA resets and account recovery

Password and MFA resets are a legitimate need, and they are also the easiest way to take over an account without defeating any technical control. If a reset can be granted on the strength of information that's easy to find, such as an employee ID, a manager's name or a date of birth, the whole MFA investment rests on that.

Build a recovery process that actually verifies identity:

  • Use verification that's hard to fake remotely. Options include an in-person check against photo ID, a live video call compared with HR records, or a callback to a phone number already on file. Don't use a number the caller provides.
  • Involve a second person for sensitive accounts. Resets for admins and executives should need approval from the person's manager or a second help desk staff member.
  • Issue temporary, single-use access. Instead of setting a known password, issue a short-lived, one-time enrollment code the user redeems to register new credentials.
  • Notify the user through an existing channel. Tell them a reset happened, so an unexpected one gets reported quickly.
  • Log every reset and include admin-initiated MFA resets in your alerting.

Protect the IdP's admin console and API tokens

Hardening user sign-ins isn't enough if the IdP's own management plane is weaker. Treat the admin console and API as the most sensitive systems you own.

  • Restrict console access to admin accounts using hardware-backed MFA on managed devices. Where your IdP supports it, also limit access to known networks.
  • Inventory API tokens. Many IdPs let admins create long-lived API tokens that inherit the creator's privileges. Find them all, record who owns each one and what uses it, and delete the rest.
  • Prefer scoped, short-lived credentials. Where available, use OAuth-based service applications with narrowly scoped permissions instead of static tokens tied to a person.
  • Store tokens in a secrets manager, never in scripts, repositories or shared documents, and rotate them on a schedule.
  • Review vendor support access. If your IdP provider can access your tenant for support, understand how that access is granted, limit it, and monitor its use.
  • Watch federation settings closely. Adding a new identity source or signing certificate can create a path to sign in as any user. Treat those changes as high-severity events.

Frequently asked questions

What is account takeover?

Account takeover is when someone other than the legitimate user gains control of an account, usually by using a stolen or reused password, a stolen session token or a weak recovery process. At the IdP level, one takeover can grant access to every connected application.

Which MFA methods hold up best against account takeover?

FIDO2 security keys and passkeys, because they're bound to the service and sign a fresh challenge every time. App-based methods with number matching are a reasonable interim step. SMS and voice codes are the weakest common options.

How many super-admin accounts should we have?

As few as you can run the business with, typically two to four named people plus two break-glass accounts. Everyone else should hold a scoped role, ideally activated just in time.

Next steps

If you're starting from scratch, work through these in order:

  1. Enforce FIDO2 security keys on every admin account and set up two break-glass accounts.
  2. Find and block legacy authentication.
  3. Roll out conditional access in report-only mode, then enforce it.
  4. Cut standing admin roles down and separate admin identities from daily accounts.
  5. Forward IdP logs to central logging and switch on the alerts listed above.
  6. Rewrite the MFA reset procedure and train the help desk on it.
  7. Inventory and clean up API tokens and review federation settings.