Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we roll out phishing-resistant MFA, and in what order?

6 decision pointsThe pack behind this answer: Privileged Access Management

Add to board memo

The short answer

Recommendation
Roll out in four stages: Tier 0 administrators, break-glass accounts and supplier Tier 0 administrators on security keys first; then every other administrator; then everyone for remote access and email; then every sign-in. Run the protocol, enrolment, recovery and break-glass checks before each stage.
Reasoning
One stolen Tier 0 credential is a compromise of the whole estate, so stage 1 starts there. Remote access and email come next for everyone because they are the routes phishing uses to take over accounts. A phishing-resistant method proves possession of a key bound to the real site, so a fake sign-in page cannot capture and replay it. Text message codes, app codes and push approvals do not count as phishing-resistant, and any weaker route left open is the one an attacker will choose.
Considerations
  • The four stages, the accepted methods and the 2 keys per person are the pack's defaults. Your own standard may set others.
  • An authenticator app with number matching is only a stop-gap for ordinary staff while keys are issued. It is never an accepted method for an administrator account (PA-05).
  • A recovery route that falls back to a text message undoes the rollout. A privileged reset needs a face-to-face or video check against the HR record, a call back to the number held there and a second administrator's approval.
  • A break-glass account left out of a sign-in policy is covered by the seal, the two-person safe, the alert, the test and the reset after use. Never leave it without a second factor where a sealed key can be used.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartPlan phishing-resistant sign-in, stage by stageStepList every account, its tier and how it signs in todayDecisionDo you know which accounts and systems are Tier 0?StepGive every system a tier before stage 1DecisionWhich stage are you starting?StepStage 1: security keys for Tier 0, break-glass and suppliersStepStage 2: keys or passkeys for every other administratorStepStage 3: passkeys or keys for everyone's remote access and emailStepStage 4: the same methods for every sign-inDecisionCan every system and protocol in the stage use the method?StepBlock it, put it behind a gateway, or record itStepEnrol in person or from an existing strong factorDecisionCan a lost key be replaced without a weaker method?OutcomeFix recovery before enforcing the policyDecisionWill a break-glass account be left out of the new policy?StepCover the gap with the seal, the alert and a sealed keyStepEnforce the method by sign-in policy for the stageDecisionDo the sign-in logs still show a weaker method?OutcomeClose each weaker route, then check againOutcomeStage enforced: start the next one

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 20 steps.

  1. Start

    Plan phishing-resistant sign-in, stage by stage

    A phishing-resistant method proves possession of a key bound to the real site, so a fake sign-in page cannot capture and replay it. The pack accepts a security key, a passkey on a managed device unlocked by the person, or a certificate on a smart card or managed device. A text message or voice code, an app or token code, a push approval with or without number matching, and an emailed link or code never count for a privileged account.

    In the pack

  2. Step

    List every account, its tier and how it signs in today

    The rollout is ordered by what an account can control, so start from the inventory of privileged accounts, with each one's tier and current sign-in method. Add the routes everyone uses: remote access, email, and every system with its own sign-in. In the pack's example, Tier 0 administrators already used security keys while staff still signed in with text message codes.

    In the pack

  3. Decision

    Do you know which accounts and systems are Tier 0?

    Tier 0 is the identity and control plane: the directory and cloud identity tenant, the identity provider and certificate services, the backup system, the endpoint protection and device management consoles, the password vault, and whatever hosts them. One stolen Tier 0 credential is a compromise of the whole estate, which is why stage 1 starts there.

    In the pack

  4. Step

    Give every system a tier before stage 1

    A system takes the tier of the most important thing it can control. Anything that can change the directory, the cloud identity tenant, the backups or the device management consoles is Tier 0, wherever it sits. Then give each directory group the tier of the systems its members can change, so you know whose accounts belong in stage 1.

    In the pack

  5. Decision

    Which stage are you starting?

    The pack rolls out in four stages: privileged accounts first, then the routes attackers phish, then everyone. Work through them in that order. The same four checks come before each stage: protocol support, enrolment, recovery and the break-glass accounts.

    In the pack

  6. Step

    Stage 1: security keys for Tier 0, break-glass and suppliers

    Stage 1 covers Tier 0 administrators, the break-glass accounts and supplier administrators with Tier 0 rights, on security keys, 2 per person by the pack's default. These are the accounts whose loss is a whole-estate compromise. Both keys are registered at enrolment, so a lost key is replaced by the spare. A break-glass account's key is sealed with its password.

    In the pack

  7. Step

    Stage 2: keys or passkeys for every other administrator

    Stage 2 covers every other administrator account and every application administrator role, on security keys or passkeys on managed devices. Where an application offers neither single sign-on nor such a method, its administrators use the strongest method it has, recorded in the inventory with the date it will move. In the pack's example, the online ordering console keeps its own app code until a planned single sign-on project.

    In the pack

  8. Step

    Stage 3: passkeys or keys for everyone's remote access and email

    Stage 3 covers everyone, for remote access and email, because those are the routes phishing uses to take over accounts. The method is a passkey or a security key. An authenticator app with number matching is allowed only as a stop-gap for ordinary staff while keys are issued, and is never an accepted method for an administrator, whose push approvals the pack rules out: an administrator account still on it is recorded in the inventory with the date it will move.

    In the pack

  9. Step

    Stage 4: the same methods for every sign-in

    Stage 4 applies the same methods to every sign-in by everyone, so no weaker route is left for an attacker to choose. Systems outside single sign-on are the usual weaker route: connect each one, or keep its local accounts listed and controlled, or close it.

    In the pack

    See also

  10. Decision

    Can every system and protocol in the stage use the method?

    This is the pack's first check before each stage. List what cannot use the new method: older mail protocols, basic authentication and network devices are the usual ones. An unsupported route left open lets the attacker sign in the old way. Not known counts as no until you have tested it.

    In the pack

  11. Step

    Block it, put it behind a gateway, or record it

    For each route that cannot use the method: block it, put it behind a gateway that can, or record it. A privileged system that can use neither single sign-on nor a phishing-resistant method uses the strongest it offers, recorded in the inventory with its date to move. Anything else left open is an exception under your exception standard, with its band's approver and expiry. The pack's exception standard gives multi-factor authentication for remote administrator access as an example of a requirement you may make impossible to except.

    In the pack

  12. Step

    Enrol in person or from an existing strong factor

    Issue keys in person, or register them from a strong factor the person already holds. Never enrol a privileged account's key from a text message code: whoever intercepts the code can register a key of their own. Register the spare key at the same sitting, and make sure each key or certificate needs the person's own PIN or fingerprint.

    In the pack

  13. Decision

    Can a lost key be replaced without a weaker method?

    For a privileged account, the spare replaces a lost key, and any reset needs a face-to-face or video check against the HR record, a call back to the number held there, and a second administrator's approval. Ordinary staff need an in-person check, or a call back and their line manager's confirmation together, and enrol the new factor themselves. A recovery route that falls back to a text message undoes the rollout. Not tested counts as no.

    In the pack

    See also

  14. Outcome

    Fix recovery before enforcing the policy

    Enforcing a method nobody can recover from pushes the service desk to bypass it under pressure. Register the spares, brief the service desk on the reset checks for privileged and ordinary accounts, and try a recovery end to end. Then ask the recovery question again.

    In the pack

  15. Decision

    Will a break-glass account be left out of the new policy?

    A break-glass account may be left out of a sign-in policy so that a fault in that policy cannot lock every administrator out. In the pack's example, exactly that happened: a sign-in policy change locked every administrator out of the cloud tenant, and a break-glass account was used to roll it back. Each exclusion is recorded and limited to the policies that could lock everyone out.

    In the pack

  16. Step

    Cover the gap with the seal, the alert and a sealed key

    The gap is covered by the seal, the two-person safe, the alert on every sign-in, the test and the reset after use. It is never covered by leaving the account without a second factor when the platform lets a sealed security key be used. Check that the account's last test is within 3 months and that its alert fired.

    In the pack

    See also

  17. Step

    Enforce the method by sign-in policy for the stage

    Require the method for the accounts in the stage through the identity provider's sign-in policy. Then read the sign-in logs. The pack's control test looks at the last 30 days of administrator sign-ins and passes only if every one used an accepted method or a recorded exception.

    In the pack

  18. Decision

    Do the sign-in logs still show a weaker method?

    Look for sign-ins in the stage by a text message or app code, a push approval, a legacy protocol, or a system that bypasses single sign-on. Each is a route an attacker will choose. Not known counts as yes until the logs are read.

    In the pack

  19. Outcome

    Close each weaker route, then check again

    Find what used the weaker method and why: a missed account, a system outside single sign-on, or an old protocol. Move it to the method, block it, or record it as the protocol check sets. Read the logs again before calling the stage done.

    In the pack

  20. Outcome

    Stage enforced: start the next one

    The stage is done when its accounts sign in only with accepted methods and every remaining gap has a date to move. The pack's example states its position that way: 6 of 8 named and supplier administrator accounts on security keys, Tier 0 done, and the two Tier 2 accounts on an authenticator app with number matching, recorded in the inventory with their move to security keys by 2 Nov 2026, in stage 2. Stage 4 is the end state: every sign-in, everywhere, on the same methods.

    In the pack

Practical checklist

  1. List every privileged account with its tier and current sign-in method, and the sign-in routes everyone uses.
  2. Give every system a tier before stage 1, so you know whose accounts belong in it.
  3. List what in the stage cannot use the method, then block it, put it behind a gateway or record it as an exception (MC-A).
  4. Enrol in person or from an existing strong factor, never from a text message code, and register the spare key at the same sitting.
  5. Test a lost-key recovery end to end, and hold the stage until recovery works without a weaker method.
  6. Record each break-glass exclusion, and check the account was tested within 3 months and its alert fired.
  7. Enforce the method for the stage's accounts by sign-in policy.
  8. Read the sign-in logs, close each weaker route found, and read them again before starting the next stage.

Evidence to have ready

  • The privileged account inventory, with each account's tier, sign-in method and any recorded date to move.
  • The sign-in policy for each stage, and the last 30 days of administrator sign-ins with the method used (CT-04).
  • Each exception for a route that cannot use the method, with its approver and expiry.
  • The break-glass checks: exclusions recorded, the last test date and whether the alert fired.

Assumptions

  • Your identity provider or single sign-on can enforce a sign-in policy for a group of accounts and register security keys or passkeys.
  • You can issue security keys in person, or register them from a factor the person already holds, and passkeys sit on devices you manage.
  • Break-glass accounts exist, or will exist before stage 1, for each cloud identity tenant, so a faulty sign-in policy cannot lock every administrator out.
  • The four stages, the accepted methods and the 2 keys per person are the CISO Times privileged access pack's defaults. Your own standard may set others.

Not covered here