Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

If…, then how…

If someone calls the help desk asking for an MFA reset, then how do we verify who they are?

6 decision pointsThe pack behind this answer: Joiner-Mover-Leaver & Access Provisioning

Add to board memo

The short answer

Recommendation
Never reset on the caller's word. For a lost second factor on an ordinary account, check photo identification in person, or call back on the HR number and have the line manager the HR record names confirm. Never reset a privileged account on a call alone.
Reasoning
A caller who persuades the service desk to reset a second factor has taken over the account, so the check comes before the reset, every time. Name, staff number, date of birth and the manager's name can all be known or found out. Every check is started by the service desk, never by the caller (JML-13). The person enrols their own new factor, because a factor someone else enrolled proves nothing about who holds it.
Considerations
  • Privileged accounts follow stricter rules: identity confirmed face to face or on video against the HR record, a call back to the HR number, and a second administrator's approval (PA-17). The ordinary checks are never enough for them.
  • If you cannot tell whether an account is privileged, use the privileged route.
  • A lost security key is replaced by the registered spare, 2 keys per person by the pack's default. There is no fallback to a text message or an app code, even for a day.
  • Urgency, seniority and details the caller supplies never replace a check. A manager who cannot be reached is a check not done.

The decision, step by step

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

  • Start
  • Step
  • Decision
  • Outcome

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

    A caller asks the service desk for a factor or password reset

    A caller who persuades the service desk to reset a second factor has taken over the account, so the check happens before the reset, every time. Details a caller can know or find out never prove identity on their own: name, staff number, date of birth, manager's name, or an email sent from the account being reset. Every check is started by the service desk, never by the caller.

    In the pack

  2. Decision

    Is it a privileged account, or might it be?

    Administrator accounts, application administrator roles and other privileged accounts follow the privileged access rules, which are stricter: the ordinary checks are the floor for ordinary accounts and never enough for privileged ones. Check the privileged account inventory. If you cannot tell, use the privileged route.

    In the pack

  3. Step

    Refuse on the call and open a ticket

    A privileged password or second factor is never reset on a call, chat or email alone, whatever the caller knows. Refuse the reset on the call and open a ticket. Callers who impersonate an administrator to get a second factor reset are behind some of the largest recent breaches.

    In the pack

  4. Step

    Confirm identity face to face or on video, and call back

    Confirm identity face to face, or on a video call with photo identity checked against the HR record. Then call back on the number held in the HR record, never one the caller gives. Record how each check was made, and the number used, on the ticket.

    In the pack

  5. Decision

    Did both checks pass, and has a second administrator approved?

    A second administrator approves the reset before it is made, and nobody resets their own account. If either identity check failed or could not be done, or no second administrator has approved, the reset is not made.

    In the pack

  6. Step

    If a key was lost, replace it with the registered spare

    Where the reset is for a lost security key, use the spare: each person with a security key holds a registered one, 2 keys in all by the pack's default. A lost key is replaced by the spare and the lost one revoked. There is no fallback to a text message or an app code, even for a day.

    In the pack

  7. Step

    Tell the owner and security; flag it for session review

    Once the reset is done, tell the account's owner and the Head of Information Security. Flag the reset for the next privileged session review, where someone with no administrator rights in that tier reviews what the account did.

    In the pack

  8. Decision

    What does the caller need reset?

    The check depends on what is being reset. A forgotten password while the second factor still works needs no call at all. A lost or replaced second factor needs the strongest of the ordinary checks, because whoever enrols the new factor controls the account from then on.

    In the pack

  9. Outcome

    Send them to the self-service password reset

    Where the person's second factor still works, they reset the password themselves with it. No call to the service desk is needed.

    In the pack

  10. Step

    Use one independent check for a password-only reset

    Where self-service is not possible, one of the three checks is enough for a password: call back on the number in the HR record, have the line manager the HR record names confirm the request, or check photo identification in person. The service desk starts the check, never the caller.

    In the pack

  11. Decision

    Can the person come in with photo identification?

    For a lost or replaced second factor, an in-person check is enough on its own: the person comes to the service desk or a named site contact with photo identification, checked against the HR record. If they cannot come in, two remote checks are needed together.

    In the pack

  12. Step

    Check their photo identification against the HR record

    The person comes to the service desk or a named site contact. The service desk or that contact compares the photo identification with the HR record before anything is reset, and notes on the ticket that the check was made in person.

    In the pack

  13. Step

    Call back on the HR number and get the manager's confirmation

    End the call and call the person back on the number in the HR record, never a number the caller gives. Separately, contact the line manager the HR record names, through a channel the service desk starts, and have them confirm the request. Both checks are needed for a second factor; either one alone is not enough.

    In the pack

  14. Decision

    Did every required check pass, started by the service desk?

    Urgency, seniority and details the caller supplies do not replace a check. If a required check failed or could not be done, the reset is not made. A manager who cannot be reached is a check not done.

    In the pack

  15. Outcome

    Do not reset; offer the in-person check instead

    Offer the in-person check, and tell the person through a second channel, their manager or the contact details in the HR record, that a reset was asked for. If the person did not ask, or the request looks like impersonation, report it at once through your incident route.

    In the pack

  16. Step

    Reset it; the person enrols their own new factor

    The service desk clears the old factor, and the person enrols the new one themselves. The service desk never enrols a factor on someone's behalf, because a factor someone else enrolled proves nothing about who holds it.

    In the pack

  17. Step

    Tell the person through a second channel; check sign-ins

    Tell the person of the reset through a second channel: their manager, or the contact details in the HR record. Then check the account's recent sign-ins and mail rules for anything the person does not recognise, such as a new forwarding rule or a sign-in from an unfamiliar place.

    In the pack

  18. Decision

    Is there anything the person does not recognise?

    A reset the person did not ask for, a sign-in they did not make or a mail rule they did not set means someone else may have had the account. If the person cannot be reached to confirm, treat it as unrecognised until they can.

    In the pack

  19. Outcome

    Report it as a possible incident; preserve the evidence

    Report it at once through your incident route. Before anything is removed, record which sessions are signed in and from where, export the sign-in log, and screenshot or export any forwarding rules and new sign-in methods. Removing them first destroys the evidence the investigation needs.

    In the pack

  20. Outcome

    Record the check used, who made it and when, in the ticket

    The reset ticket, with the identity check used, is the record the policy expects. Write which check was made, by whom and when, in your own service desk ticket. Privileged resets are counted with privileged access, not with the service desk's ordinary resets.

    In the pack

Practical checklist

  1. Check the privileged account inventory first, and use the privileged route if you cannot tell.
  2. Send a forgotten password to self-service where the person's second factor still works.
  3. For a password where self-service is not possible, use one check: call back, line manager confirms, or photo identification in person.
  4. For a lost or replaced second factor, check photo identification in person, or use the call back and the line manager's confirmation together.
  5. Refuse the reset if a required check failed or could not be done, and offer the in-person check.
  6. Clear the old factor and let the person enrol the new one themselves.
  7. Tell the person through a second channel, and check recent sign-ins and mail rules for anything they do not recognise.
  8. Report anything unrecognised through your incident route, recording sign-ins and rules before removing them.

Evidence to have ready

  • The reset ticket, with the identity check used, who made it and when (JML-13).
  • For each privileged reset, the face-to-face or video check, the call back with the number used, and the second administrator's approval (PA-17).
  • For a lost security key, the spare registered and the lost key revoked.
  • Each privileged reset flagged for the next session review, and the review that covered it.

Assumptions

  • The HR record holds each person's phone number and line manager, and the service desk can reach both without going through the caller.
  • Privileged accounts are known from an inventory, each holder has a spare security key registered, and a second administrator is available to approve a privileged reset.
  • People can enrol their own new factor once verified, and ordinary staff can reset a forgotten password themselves while their second factor still works.

Not covered here