Why Security Asked You to Confirm Something You Did Yesterday

TL;DR — Security is usually asking because their monitoring saw an action that looked risky or unusual, but not risky enough to prove it was an attacker. The most likely fix is simple: reply quickly with whether you did it, from where, and on what device, so they can either close the alert or contain a real account compromise before it spreads. Reading time: ~7 min

What it is and where it sits

When a security team asks, “Did you really do this yesterday?”, they are usually following up on an alert from an XDR system (Extended Detection & Response: tooling that combines signals from devices, apps, identity systems, email, and cloud services to spot suspicious behavior).

In plain English: the system noticed an action that was real, but ambiguous.

Examples:

• a login from a new city
• a password reset followed by a large file download
• an admin setting change outside normal hours
• a mailbox rule added after a suspicious sign-in
• a user granting a third-party app access to company data

The security team is not asking because they are unsure how logs work. They are asking because logs can show what happened, but often not why. Your confirmation supplies the missing business context.

Where it sits in the architecture

In a typical company setup, your apps and systems send activity records to several places:

• the identity provider (IdP: the system you sign into first, such as your company login portal)
• the application itself (CRM, file storage, email, admin console)
• the endpoint tool on your laptop (security software on the device)
• the cloud platform audit log
• a central security platform such as SIEM/XDR (Security Information and Event Management / Extended Detection & Response)

Years ago, teams often relied on separate tools: antivirus for laptops, a log search tool for servers, and manual review for cloud apps. XDR tries to replace that fragmented view with one place that correlates events across systems.

That matters because a single event may look harmless alone. Combined with other events, it can look like account takeover (someone else using your account) or insider misuse.

[User] ---- 1. sign-in / action ----> [App or Admin Portal]
  |                                      |
  | 2. device telemetry                  | 3. audit log
  v                                      v
[Endpoint Tool] ---- 4. events ----> [XDR / SIEM] <---- 5. identity events ---- [IdP]
                                         |
                                         | 6. alert: unusual sequence
                                         v
                                  [Security Analyst]
                                         |
                                         | 7. asks user to confirm
                                         v
                                      [You]

In that flow, the security team sits after the systems have already collected and correlated the data. Their question to you is the final decision step before they either close the case or start containment.

How it actually works

Here is one realistic example: yesterday, you exported customer records from your CRM after logging in from a hotel Wi‑Fi network while traveling.

To you, that may be normal. To the XDR system, it can look like a stolen account being used to exfiltrate data (exfiltrate: move data out of the company).

Step-by-step example

1. You sign in from a new location The identity system records a successful login from a city or IP address (internet address) it has not seen for your account before.

2. Your laptop may look slightly different than usual Maybe you used a browser you do not normally use, or your device checked in later than normal because you were offline on a flight. That weakens the “this is definitely the usual user” signal.

3. You perform a sensitive action In the CRM or file system, you export a large report, change permissions, or download many files.

4. The systems send logs to the XDR platform The IdP sends sign-in details. The app sends audit events like “export completed.” Your device tool may send “managed laptop seen” or “device missing recent heartbeat.”

5. The XDR correlates the events Instead of treating these as separate facts, it links them into one story:

   • new location
   • unusual time of day
   • high-value action
   • possible mismatch with normal device pattern

6. A detection rule or behavior model fires This can be a simple rule such as “new country + admin action within 2 hours,” or a behavior model such as “download volume is 10x above user baseline.”

7. A human analyst reviews the alert Good security teams do not immediately lock every account. The analyst checks what else happened around the same time:

   • Was MFA (multi-factor authentication: a second sign-in check) completed?
   • Was the device managed?
   • Did email rules get added?
   • Were there failed logins before the success?
   • Is there a travel notice or approved change request?

8. They still need one fact only you know The missing fact is intent and legitimacy. Were you traveling? Did your manager ask for the export? Was it your device?

9. They contact you the next day Often not instantly, because the alert may have arrived overnight, entered a queue, or required correlation before it looked serious enough to investigate.

10. Your answer changes the response path

• If you confirm: “Yes, I was in Chicago, on my company laptop, exporting records for the QBR,” they document it and tune the alert if needed.
• If you deny it: they may revoke sessions, reset your password, block tokens, and review what data was accessed.
• If you are unsure: they usually treat it as suspicious until proven otherwise.

The key idea: the question is not random. It is the last mile of detection.

When to use it (and when not to)

From the security team’s point of view, asking the user is appropriate when the evidence is suggestive but not conclusive.

You probably do not need this if...

You probably do not need a user-confirmation step as the primary control if:

• the action is already covered by an approval workflow in the app
• the change is tied to a ticket or maintenance window the security team can check directly
• the event is clearly benign and happens often for that role
• the event is clearly malicious and delay increases damage

In other words, user confirmation is best for the gray area in the middle.

Trade-offs

Every benefit here comes with a cost.

• Benefit: fewer false positives Cost: it interrupts users and depends on them replying accurately.

• Benefit: preserves business continuity Instead of locking accounts immediately, the team can verify first. Cost: waiting for confirmation can give a real attacker more time.

• Benefit: adds business context logs do not contain Cost: users may forget details, especially if asked a day later.

• Benefit: helps tune detections over time Confirmed benign cases teach the team what “normal” looks like. Cost: tuning takes analyst time, and some tools charge more as more data sources are connected.

• Benefit: catches cross-system attacks XDR sees identity, endpoint, and app signals together. Cost: more integration work, more operational overhead, and some vendor lock-in (difficulty moving away after many systems are connected).

• Benefit: less guesswork than single-tool alerts Cost: correlation can add delay, and some detections are probabilistic rather than definitive.

For customers, the practical takeaway is simple: a quick, precise answer helps security avoid both overreaction and underreaction.

In practice

Below are two concrete examples: one from the user side, one from the security/admin side.

Example 1: How to reply usefully to a confirmation request

If security messages you in email or chat, a useful reply looks like this:

Yes, that was me.
Time: around 3:15 PM local time yesterday
Action: exported customer list from the CRM
Location: Chicago hotel Wi‑Fi
Device: company MacBook
Reason: preparing slides for the quarterly business review

What it does: this gives the analyst the exact facts they need to compare against the logs. The gotcha: do not click links in a suspicious message asking for confirmation; if in doubt, open your company chat or help desk separately and reply there.

Example 2: Check your recent sign-ins in a typical identity dashboard

In your provider's dashboard, look for a path similar to:

• Profile picture → My Account → Security → Recent activity
• or Account Settings → Security → Sign-in activity

If your organization uses Microsoft Entra ID, admins often review sign-ins with a command like:

az rest --method get --url "https://graph.microsoft.com/v1.0/auditLogs/signIns?$top=5"

What it does: fetches recent sign-in records from Microsoft Graph for review. The gotcha: this requires admin permissions and the Azure CLI already signed in; most end users will not have access, so the dashboard path is the right first step.

Example 3: Review cloud audit events around the reported time

If the action involved cloud settings, an admin might inspect audit logs in the provider dashboard, for example:

• Your cloud provider's dashboard → Audit Logs / Activity History
• then filter by your username, the date, and the service involved.

For AWS, a common CLI check is:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=jane.doe --max-results 10

What it does: shows recent CloudTrail events for a specific username. The gotcha: usernames in audit logs may be role names, federated identities, or service accounts rather than the human-friendly email address you expect.

⚠️ If security tells you they suspect the action was not yours, do not start “cleaning up” by deleting files, revoking random app access, or changing shared settings on your own. That can destroy evidence or interrupt service. The safe first action is to contact security through the official help desk or chat channel and follow their containment steps.

A good response sequence is:

1. Open the official support or security channel yourself.
2. Confirm whether the message really came from your company.
3. State whether the action was yours.
4. If it was not yours, ask them to sign you out of all sessions and reset your credentials.
5. Check recent activity in your account dashboard and note anything unfamiliar.

Further reading

• NIST Special Publication 800-61, "Computer Security Incident Handling Guide"
• MITRE ATT&CK, the "Credential Access" and "Exfiltration" tactics
• Microsoft Learn, the "Investigate sign-in logs" sections for Entra ID
• AWS CloudTrail User Guide, the "Viewing Events with Event History" section
• The "Authentication" and "HTTP Logging" sections of the MDN Web Docs

This article was written by an AI system and published pending human review. Verify anything you intend to act on.