Before
The service desk manually reviewed the account, group memberships, MFA history, and recent sign-in events after completing an identity check. An agent then decided whether to reset the factors, update the incident, contact the manager, notify the user, or involve the SOC, often copying findings between these actions.
How it works
- Receive the approved identity-check event and assess the supplied account, group, MFA-factor, and sign-in evidence.
- Apply fixed rules covering account status, login matching, verification method, verifier separation, sensitive access, evidence completeness, and low assessed risk.
- Reset MFA and notify the relevant parties when all controls pass; otherwise update the incident and alert the SOC for further verification.
Workflow details
- Trigger and evidence review: A ServiceNow identity-check approval starts the workflow with the incident, user login, verification method, and verifier. The workflow reviews the supplied account, group, MFA-factor, and recent sign-in evidence, including indicators such as denied pushes from an unfamiliar network.
- Risk normalization: The assessment is accepted only when the required evidence has been checked. A low-risk result is not trusted if the system log or MFA-factor history was not reviewed, and incomplete or invalid assessments are treated as insufficient.
- Fixed authorization rules: The workflow permits a reset only when the account is identified and active, the login matches the account, the verification method is approved, the verifier is present and different from the requester, no sensitive group is detected, and the assessed risk is low.
- Approved reset path: When every control passes, the workflow resets the user’s MFA factors, records the verification and decision in ServiceNow, and sends re-enrollment instructions to the user. It also notifies the manager so an unrecognized request can be reported.
- Escalation path: When any control fails, the workflow does not reset MFA. It updates the incident for SOC handling, records the specific blocking reasons and risk summary, and alerts the SOC with instructions to verify the user through known directory contact details.
What changed
The reset decision is now produced automatically after the identity check, with evidence completeness and fixed risk controls evaluated before any factor reset. Approved requests proceed to the reset, incident update, and notifications, while failed checks create a documented SOC handoff instead of leaving the service desk to coordinate the next action.
Work removed
Reviewing account and sign-in evidence one request at a time, checking MFA and group-risk conditions, validating the verifier and method, copying decision reasons into the incident, opening notification chats, and manually notifying the user, manager, or SOC.
Expected outcome
Expected outcome is a consistently documented reset-or-escalate decision for every request, with several manual review, ticket-update, and notification actions removed on the approved path.
