Agent Foskett Academy • SOC Analyst Academy • Module 3 • Lesson 23 • Identity Incidents

Lesson 23 — A New MFA Method Appeared After the Sign-In

The suspicious sign-in happened at 02:54.

At 03:02, a new authentication method was registered for the same user. The helpdesk had not changed anything. The user said they had not added a new method.

The sign-in was important. The authentication-method change was worse. It suggested the attacker may have moved from temporary access to identity persistence.

A new MFA method after suspicious access can turn a sign-in incident into a persistence investigation.

Investigate the MFA Change Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy investigating a new MFA method registered after a suspicious sign-in

The sign-in was not the end

Authentication-method changes can create durable access. The analyst must connect who signed in, when the method changed, what was added and what happened afterwards.

✓ Identify the authentication-method change

✓ Correlate it with sign-in activity

✓ Validate whether the user made the change

✓ Check for persistence and follow-on activity

Case briefing

02:54 — SUCCESSFUL SIGN-IN UNFAMILIAR SOURCE 02:58 — CLOUD ACTIVITY NOT NORMAL FOR USER 03:02 — AUTHENTICATION METHOD ADDED NEW MFA METHOD 03:05 — ANOTHER SUCCESSFUL SIGN-IN USER RESPONSE "I DIDN'T ADD ANYTHING." THE EASY VERDICT "Reset the password." THE SOC QUESTION "Did the attacker create a new way to authenticate after gaining access?"

Investigation objective

Determine whether a newly registered authentication method was legitimate, accidental or added by an attacker after compromising the account.

Investigator's rule

Identity changes after suspicious access must be treated as timeline evidence. A new MFA method may create persistence even if the original password is later changed.

Stage 1 — establish exactly what changed

Question	Why it matters
What authentication method was added?	Phone, authenticator app, FIDO2/passkey or another method creates different investigation paths.
When was it added?	The timestamp determines whether it followed suspicious access.
Who initiated the change?	User, administrator, self-service registration or attacker activity can produce different evidence.
Was the change expected?	Helpdesk tickets and user confirmation can validate legitimate activity.
Was the new method used later?	Use after registration strengthens the persistence hypothesis.

Timing is critical

A new authentication method added months after a sign-in may be unrelated. A method added eight minutes after suspicious access deserves immediate attention.

User confirmation matters

If the user says they did not register the method, that is strong supporting evidence. It still needs to be reconciled with Microsoft Entra audit and sign-in telemetry.

Stage 2 — investigate authentication-method changes with KQL

Search Microsoft Entra audit data for authentication-method activity around the suspicious sign-in window.

12345 678910 1112131415 161718

let TargetUser = "s.bennett@contoso.com";
AuditLogs
| where TimeGenerated > ago(24h)
| where tostring(TargetResources) has TargetUser
| where OperationName has_any (
    "authentication",
    "security info",
    "MFA",
    "method"
)
| project TimeGenerated,
          OperationName,
          Result,
          InitiatedBy,
          TargetResources,
          AdditionalDetails
| order by TimeGenerated asc

Audit logs tell you that something changed

The exact operation names and available details can vary, so the analyst should inspect the returned records rather than rely on one hard-coded event name.

Preserve the raw event

Before reducing the event to a short finding, keep the original audit record. Initiator, target resources and additional details may matter later.

Stage 3 — correlate sign-ins and method changes

02:54 SUSPICIOUS SIGN-IN ↓ 02:58 UNUSUAL CLOUD ACTIVITY ↓ 03:02 NEW AUTHENTICATION METHOD ↓ 03:05 NEW SUCCESSFUL SIGN-IN ↓ QUESTION DID THE NEW METHOD ENABLE OR SUPPORT CONTINUED ACCESS?

Sequence creates meaning

The authentication-method change becomes much more significant when it sits between suspicious access and later successful activity.

Do not stop at password compromise

If the attacker registered a new method, resetting the original password may not address every route of access. Remediation must consider the identity configuration itself.

Stage 4 — build a combined identity timeline

Use sign-in logs to reconstruct access immediately before and after the authentication-method change.

12345 678910 11121314 151617

let TargetUser = "s.bennett@contoso.com";
SigninLogs
| where TimeGenerated between (
    datetime(2026-08-24 02:30:00) ..
    datetime(2026-08-24 03:30:00)
)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          ResultType,
          ResultDescription,
          AuthenticationDetails
| order by TimeGenerated asc

Compare before and after

Look for a change in source, authentication details or application behaviour after the new method was registered.

A method can be persistence

If an attacker can authenticate again using a method they registered, the identity incident has moved beyond credential theft into persistence.

Stage 5 — test legitimate explanations

Hypothesis	Evidence to test
User added a new phone or authenticator	User confirmation, expected device, normal location and legitimate registration timing.
Helpdesk-assisted registration	Ticket history, administrator audit events and approved change context.
Security-registration campaign	Organisation-wide rollout, expected timing and matching changes for other users.
Attacker-established persistence	Suspicious sign-in followed by method registration and later use of the new method.

Stage 6 — remediation must remove persistence

SUSPECTED COMPROMISE ↓ RESET PASSWORD ↓ REVOKE ACTIVE SESSIONS ↓ REVIEW AUTHENTICATION METHODS ↓ REMOVE UNAUTHORISED METHOD ↓ REQUIRE SECURE RE-REGISTRATION ↓ CHECK PRIVILEGE / CONSENT / MAILBOX CHANGES ↓ MONITOR FOR RE-ENTRY

Do not remove evidence too early

Containment is important, but document the suspicious method and relevant audit details before removal so the investigation remains defensible.

Expand the persistence hunt

If one identity change was made after compromise, look for others: OAuth consent, role activation, mailbox rules, app registrations or additional authentication changes.

Stage 7 — make the SOC decision

NEW MFA METHOD DETECTED ↓ IDENTIFY WHAT CHANGED ↓ CORRELATE WITH SIGN-IN TIMELINE ↓ VALIDATE USER / HELPDESK ACTIVITY ↓ CHECK WHETHER METHOD WAS USED ↓ FOLLOW POST-CHANGE ACTIVITY ↓ TEST LEGITIMATE EXPLANATIONS ↓ CONTAIN PERSISTENCE ↓ ESCALATE / CLOSE / CONTINUE

An authentication-method change is not just configuration data. In the right timeline, it can be persistence evidence.

Write the investigation finding

IDENTITY TRIAGE FINDING A suspicious successful sign-in occurred for s.bennett@contoso.com at 02:54. At 03:02, a new authentication method was registered for the same identity. The user confirmed they did not add the new method. The registration occurred after suspicious access and before further successful activity. DECISION Escalate and contain the identity incident. Remove the unauthorised authentication method, revoke active sessions and require secure re-registration after password remediation. REASON The timing of the sign-in, method registration and later activity supports the hypothesis that the attacker attempted to establish identity persistence.

Lesson 23 key takeaways

New authentication methods should be correlated with suspicious sign-in activity.
Timing can turn a routine configuration event into high-value persistence evidence.
Use Microsoft Entra audit logs to investigate authentication-method changes.
Preserve the raw audit event before simplifying the finding.
Compare sign-ins before and after the method registration.
User and helpdesk confirmation help validate whether the change was expected.
A password reset alone may not remove attacker-established authentication persistence.
Review and remove unauthorised authentication methods during containment.
Expand the investigation to other persistence mechanisms after identity compromise.
Build the final verdict from the complete identity timeline.

Module 3 — Identity Incidents

Lesson 23 shows how attackers may convert access into persistence by changing authentication methods. Next, Agent Foskett investigates a Conditional Access result that looked successful but did not explain the whole sign-in.

Next: Lesson 24 — Conditional Access Said Success — What Actually Happened?

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 3: Identity Incidents

Investigate suspicious authentication, identity changes and persistence across Microsoft Entra activity.

← Previous lesson

Lesson 22 — The User Received Twelve MFA Prompts Investigate MFA fatigue and repeated authentication attempts.

✅ Current lesson

Lesson 23 — A New MFA Method Appeared After the Sign-In Correlate authentication-method changes with identity activity.

Next lesson

Lesson 24 — Conditional Access Said Success — What Actually Happened? Interpret Conditional Access in the wider sign-in story.

How to investigate a newly registered MFA method in Microsoft Entra

Lesson 23 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate new authentication methods, correlate those changes with suspicious sign-ins and determine whether an attacker attempted to establish identity persistence.

KQL investigation of Microsoft Entra authentication-method changes

Learn how to use AuditLogs and SigninLogs with KQL to review authentication-method activity, correlate identity changes with sign-in timelines and identify suspicious persistence after account compromise.