CSX Vishing Breach: Hardening Microsoft 365 Against Help Desk Calls

Freight railroad CSX began notifying individuals on 20 October 2026 that an employee responded to a voice phishing (vishing) call on 29 May, giving an outsider access to its Microsoft 365 environment. Files were accessed and taken until 9 June. Some held names with Social Security, driver's licence or bank details. Any Microsoft 365 tenant can blunt this pattern today.

There is no CVE here, no patch to apply and no vulnerable library to upgrade. The control that came under pressure was a phone conversation. That makes this incident unusually useful for every Microsoft 365 administrator, because the same pattern has been described against many organisations this year, and almost every defence against it is a setting you already own. This post sets out what CSX's notices say and what they leave open, then walks through Microsoft's own documented controls for phishing resistant sign in, locked down security info registration, Temporary Access Pass hygiene, help desk caller verification, and the audit log searches you would run if a call like this ever succeeded in your tenant.

A word on tone before the details. CSX detected the activity through an alert, notified law enforcement, reviewed the files and is notifying the people involved. Nothing in the public record suggests anything unusual about its response, and this post does not speculate about its internal controls. The lessons below are written for any team running Microsoft 365.

What happened

CSX's notice letters were filed with state attorneys general beginning 20 October 2026. The New Hampshire Department of Justice posts these filings as PDFs; the CSX filing dated 20 October returned an access error when we tried to fetch it, so the details below come from the Vermont Attorney General's breach list (fetched directly) and from two claims sites that summarise the filings. Where a fact rests only on a summary, we say so.

According to the notice as summarised by ClaimDepot, an employee "responded to a vishing call," and that response gave an unauthorized party access to CSX's Microsoft 365 environment. The unauthorized party then accessed and acquired certain files between 29 May and 9 June 2026. CSX became aware in June when it was alerted to unusual activity on the employee's account. On 26 August 2026 CSX determined that one or more of the affected files contained personal information, and individual notices began on 20 October.

Timeline

No primary source we could read publishes times of day for any of these events, so this table is at day level. If CSX or a regulator publishes a fuller account, the times will appear in the linked filings.

The gaps between those dates

The intervals are worth stating plainly, because they are the part of this story every team can measure in its own process.

None of these numbers is unusual for a file theft incident. File review is slow everywhere because a stolen folder of spreadsheets and PDFs has to be opened, parsed and matched to real people before anyone can be told. The point for defenders is that two of those three intervals are things you can shorten before an incident happens: how long a stolen session stays useful, and how quickly you can say which files held personal data.

Technical details

This section collects the concrete values published about the incident, followed by the Microsoft platform values a defender needs to reproduce the investigation in their own tenant. Every value is attributed.

What the notices disclose

What the notices do not disclose

There are no indicators of compromise in any public source: no IP addresses, domains, phone numbers, user agents or file hashes. The notices as summarised also do not say:

• what the caller claimed to be, or what the employee was asked to do (approve a prompt, read out a code, visit a page, register a new sign in method);
• which Microsoft 365 workloads were touched (SharePoint, OneDrive, Exchange mailboxes, Teams files);
• whether there was any extortion demand;
• who was responsible.

We do not link this incident to any named threat group. The technique context below comes from reporting on other campaigns, and it is there to explain how vishing against Microsoft 365 generally works, not to suggest who called CSX.

Microsoft 365 values defenders need

These are the platform facts you will rely on if you run the checks later in this post. All come from Microsoft Learn pages we fetched.

Audit operation names to search

Operation names must be typed exactly, Microsoft warns, or the search returns nothing.

How vishing reaches Microsoft 365

This section explains the general technique in plain terms, using reporting about other campaigns. It describes no step that is specific to CSX, because CSX has not published one.

A vishing call is a phishing attempt delivered by voice. In the version most often described against Microsoft 365 this year, the caller claims to be internal IT. Help Net Security's September summary of Arctic Wolf research, on a cluster Arctic Wolf tracks separately, describes callers telling employees they need to complete routine passkey or MFA setup, then sending a link to a sign in page styled as the company's own. That page relays the real Microsoft sign in, so the employee types a genuine password and approves a genuine prompt, and the operator captures an authenticated session. Help Net Security reports that the operators then review the account, map SharePoint sites and bulk collect from SharePoint, OneDrive and mailboxes.

The reverse direction works too. A caller can ring the help desk claiming to be an employee who has lost a phone, and ask for MFA to be reset or a new method to be added. Microsoft's own Verified ID guidance names the problem directly: verifying callers "especially in remote interactions via phone" is hard, and knowledge based checks fail against attackers using social engineering and AI voice cloning.

Either way, the outcome is the same. The intruder ends up holding a valid session or a valid new sign in method, and from Microsoft 365's point of view the activity that follows is the employee's own. That is why three kinds of control matter, in this order:

1. Sign in methods that cannot be relayed. A passkey or FIDO2 key is bound to the real site's origin, so a look alike page cannot use it. CISA calls phishing resistant MFA "the gold standard" and lists FIDO/WebAuthn and PKI based methods in that tier. App codes and push approvals, even with number matching, are a tier below because a person can still be talked into using them on the wrong page.
2. A locked door on adding new sign in methods. If the intruder cannot register a new authenticator from an unfamiliar network or device, a stolen password plus a talked out approval gets them much less.
3. Fast, specific detection and evidence. The CSX notice says an unusual activity alert fired. The next questions are always the same: which files, from where, for how long. Those answers come from the unified audit log, and its retention and limits decide how fast you can answer.

Why this is a supply chain story

Safeguard writes mostly about software supply chains, and this incident has no package in it. It still belongs here. The files that left held personal information about individuals, and a claims site says those people include current and former employees and third parties, which would mean people well beyond the account holder now carry the consequences. Identity is the supply chain that every other supply chain runs on: your source code host, your CI system, your package registry tokens and your cloud consoles all sit behind the same sign in. A help desk that can be talked into adding a method is a shared dependency of all of them.

Who is affected

A practical note for anyone who received a letter: the people most likely to call you about a data breach next week are scammers who read the same news. Microsoft's guidance about help desks applies at home too. If someone calls about your CSX letter, hang up and call the number printed on the letter itself.

What to do now in your Microsoft 365 tenant

These steps come from Microsoft Learn. Use report only mode first wherever Microsoft offers it, and exclude your emergency access accounts from every Conditional Access policy, as Microsoft recommends, so a mistake cannot lock everyone out.

1. Confirm the audit log is on and know your retention

Run this in Exchange Online PowerShell, not Security & Compliance PowerShell. Microsoft notes the property always reads False in the latter even when auditing is on.

Connect-ExchangeOnline
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

True means audit log search is on. Then check which licences your users hold. With Audit (Standard), records are kept for 180 days. With E5 class licences, Entra ID, Exchange and SharePoint records are kept for one year by default.

Do the arithmetic for your own worst case. An intrusion on 29 May that is first investigated in depth months later is working against a 180 day clock: records from 29 May age out of Audit (Standard) around 25 November. If your incident response plan assumes you can always go back and look, export the relevant records to storage you control as the first act of any investigation.

2. Require phishing resistant MFA, starting with the riskiest people

Microsoft's authentication strengths let you require a specific class of method in Conditional Access. A safe rollout order is administrators first, then executives and their assistants, then finance, HR and help desk staff, then everyone.

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID, then Conditional Access, then Policies, and select New policy.
3. Name it, for example Require phishing resistant MFA for privileged and finance users.
4. Under Assignments, include the target group and exclude your emergency access accounts.
5. Under Target resources, choose the resources you want covered. All resources gives the broadest protection.
6. Under Access controls, then Grant, select Require authentication strength and choose Phishing-resistant MFA strength.
7. Set Enable policy to Report-only and create the policy.
8. Review the report only results, make sure every person in scope has registered a passkey, security key, Windows Hello for Business or certificate, then switch the policy to On.

Two limits from Microsoft's documentation to plan around. First, you cannot combine Require multifactor authentication and Require authentication strength in the same policy. Second, authentication strength is evaluated after the first factor, so users can still type a password; the policy then demands the strong method before they continue.

You can confirm the built in strengths with Microsoft Graph:

Connect-MgGraph -Scopes "Policy.Read.All"
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies?`$filter=policyType eq 'builtIn'"

3. Lock down security info registration

This is the policy that most directly answers "a caller talked someone into adding a method." It applies Conditional Access to the act of registering a new authenticator. Microsoft's documented steps:

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID, then Conditional Access, then Policies, and select New policy.
3. Name it, for example Combined Security Info Registration with TAP.
4. Under Assignments, then Users or workload identities, include All users. Exclude All guest and external users and your emergency access accounts.
5. Under Target resources, then User actions, check Register security information.
6. Under Conditions, then Locations, set Configure to Yes, include Any location and exclude All trusted locations.
7. Under Access controls, then Grant, select Require authentication strength and pick the strength you want.
8. Set Enable policy to Report-only, create it, review the impact, then switch it On.

With this in place, someone registering a new method from outside your trusted locations must already prove a strong method, or hold a Temporary Access Pass that an administrator issued after verifying them. Microsoft notes that from 6 July 2026 these policies also apply when people register Windows Hello for Business and macOS Platform SSO credentials, so test any existing registration policy again if you have not done so since July.

A caution about trusted locations: if your office or VPN egress is a trusted location, an intruder who already holds a session on a device inside it is not challenged by this policy. Keep the trusted list short, and consider requiring the strong method everywhere for the highest risk groups.

4. Make Temporary Access Pass the only recovery path, and keep it short

A Temporary Access Pass (TAP) is a time limited passcode that lets someone sign in and register a new method. It is exactly what a help desk should hand out after verifying a caller, and exactly what an intruder wants to talk a help desk into issuing. Configure it deliberately.

1. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.
2. Browse to Entra ID, then Authentication methods, then Policies, and select Temporary Access Pass.
3. Enable it and scope it to the users who should be able to use one.
4. Select Configure. Consider setting One-time use to true and a short default lifetime. The defaults are a 1 hour default lifetime, an 8 hour maximum, and one time use set to false.
5. Save.

Issuing a single use pass with Microsoft Graph PowerShell looks like this:

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"
$properties = @{ isUsableOnce = $true; lifetimeInMinutes = 60 } | ConvertTo-Json
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "user@contoso.com" -BodyParameter $properties

Two details from Microsoft's page matter for incident response. Tokens issued during a TAP sign in are capped at the pass's expiry when issued, but expiry does not end sessions already established, so session length is governed by your Conditional Access session controls. And each user can hold only one TAP at a time; a new one overrides the old.

Restrict who can issue passes. Microsoft lists Privileged Authentication Administrators (for admins and members) and Authentication Administrators (for members). Keep those role holders few, and review assignments regularly.

5. Give the help desk a verification step that a voice cannot fake

Microsoft's Verified ID help desk pattern describes two routes. In the first, the caller authenticates with their existing strong credential before the help desk will do anything, for example through a support channel that requires Entra sign in. In the second, for someone who has lost every method, the help desk asks them to present a VerifiedEmployee credential with Face Check, and only after a successful check does it reset a password, issue a TAP or onboard MFA. Microsoft publishes a sample help desk web app and a sample that issues a TAP after verification.

Not every organisation will deploy Verified ID this quarter. The rules behind it can be adopted today in a written runbook:

• The help desk never resets MFA, adds a method or issues a TAP on an inbound call alone.
• Verification uses a channel the caller did not choose: a call back to the number in the HR system, a video check against a badge photo, or confirmation from the person's manager through a separate channel.
• Executives, their assistants and finance staff get a higher bar, because they are the most frequent targets in the campaigns described this year.
• Help desk staff are told, in writing, that refusing a pushy caller is always the right answer and never a performance problem.
• Every reset, method registration and TAP issue gets a ticket number, so the audit log entry can be matched to a request.

The reverse direction needs its own rule, sent to every employee: IT will never call you and ask you to approve a prompt, read out a code, or register a passkey on a link they send. If someone does, hang up and call the help desk number from the intranet.

6. Hunt for method registrations you cannot explain

Every new authenticator should match a ticket. In the Entra admin center, browse to Entra ID, then Monitoring & health, then Audit logs, filter Service to Authentication Methods, and look for User registered security info and Admin registered security info. With Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "AuditLog.Read.All"
$since = (Get-Date).AddDays(-30).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogDirectoryAudit -All -Filter "loggedByService eq 'Authentication Methods' and activityDateTime ge $since" |
  Where-Object { $_.ActivityDisplayName -in @('User registered security info','Admin registered security info','User changed default security info') } |
  Select-Object ActivityDateTime, ActivityDisplayName,
    @{n='Target';e={$_.TargetResources[0].UserPrincipalName}},
    @{n='InitiatedBy';e={$_.InitiatedBy.User.UserPrincipalName}},
    @{n='IP';e={$_.InitiatedBy.User.IpAddress}}

Join that list against your help desk tickets. A registration with no matching ticket, from an address your organisation does not use, within a day of a sign in from a new location, deserves a phone call to the user on a number you already hold.

7. Search for bulk file access in the unified audit log

If an account is suspected, scope the search to that account and the window. -SessionCommand ReturnLargeSet with a fixed -SessionId pages through up to 50,000 results; rerun the same command until it returns nothing.

Connect-ExchangeOnline
$user  = "employee@contoso.com"
$start = "2026-05-29 00:00:00z"
$end   = "2026-06-10 00:00:00z"
$ops   = "FileAccessed","FileDownloaded","FileCopied","FileMoved","MailItemsAccessed","New-InboxRule","Set-InboxRule","UpdateInboxRules"
$all   = @()
do {
  $page = Search-UnifiedAuditLog -StartDate $start -EndDate $end -UserIds $user `
          -Operations $ops -SessionId "suspect-$user" -SessionCommand ReturnLargeSet -ResultSize 5000
  $all += $page
} while ($page.Count -gt 0)

$all | ForEach-Object {
  $d = $_.AuditData | ConvertFrom-Json
  [pscustomobject]@{
    TimeUtc   = $d.CreationTime
    Operation = $d.Operation
    ClientIP  = $d.ClientIP
    UserAgent = $d.UserAgent
    Object    = $d.ObjectId
  }
} | Export-Csv ".\suspect-activity.csv" -NoTypeInformation

Then summarise: downloads per hour, distinct client IPs, distinct user agents, and the sites or folders touched. A person working normally opens a handful of files from a few sites. Bulk collection looks like hundreds of FileDownloaded or FileAccessed events across many sites in a short period, often from an address the user has never signed in from.

To check who touched a specific sensitive site, Microsoft's reference shows the -ObjectIds filter with a trailing wildcard:

Search-UnifiedAuditLog -StartDate "2026-05-29" -EndDate "2026-06-10" `
  -ObjectIds "https://contoso.sharepoint.com/sites/hr/*" `
  -SessionId "hr-site" -SessionCommand ReturnLargeSet

In the Microsoft Purview portal the same search is under Audit, with an operations names field where you type exact operation names. Search jobs keep running after you close the browser, and completed jobs are kept for 30 days. Remember that records typically appear 60 to 90 minutes after the event, so do not conclude that nothing happened from a search run minutes after an alert.

8. Contain a suspected account

Microsoft's emergency revocation steps for a cloud only user, in Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$User = Get-MgUser -Search UserPrincipalName:'employee@contoso.com' -ConsistencyLevel eventual
Update-MgUser -UserId $User.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $User.Id
Get-MgUserRegisteredDevice -UserId $User.Id -All | ForEach-Object {
  Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false
}

For hybrid users, Microsoft says to disable the account in on premises Active Directory and reset the password twice there as well. Revocation stops new tokens, but Microsoft is clear that access tokens issued earlier stay valid until they expire, one hour by default, and applications with their own session cookies keep their sessions until those expire. Continuous Access Evaluation narrows that window for applications that support it.

After containment, remove every authentication method the user did not register themselves, then enrol the user again in person or through a verified TAP.

9. Limit how much one account can reach

The CSX notice says the files that left contained personal data that took weeks to identify. The best time to shorten that review is before an incident:

• Keep Social Security numbers and bank details out of general purpose file shares. Put them in systems built to hold them, with narrower access.
• Review who can reach HR, payroll and finance sites. Remove "everyone" style grants.
• Label sensitive files so that, after an incident, you can list the affected files by label rather than opening each one.
• Microsoft's revocation guidance also points to Defender for Cloud Apps to block data downloads where appropriate.

What changed since first reports

The story is three days old and has moved mostly in how it is described, not in its facts.

• Primary filing access. The New Hampshire PDF that first carried the notice returned an access error to us. The Vermont listing is the only primary record we could read directly, and it does not include the letter text. Vermont says it no longer posts third party notice PDFs; copies can be requested by email.
• Counsel. Early desk notes named a law firm as CSX's outside counsel for the filing. We could not confirm that from any readable source, so this post does not name one.
• "Customer data." A law firm press release on 22 October used the phrase "customer data is exposed" in its headline. The notice summaries describe personal information about individuals in files; a claims site says they include current and former employees and third parties. We could not open that release to check its body, and we use the notice's framing.
• Counts. Vermont lists 9 residents. A claims site reports at least 57 in New Hampshire. No total has been published.
• Data fields. The Vermont list uses its own categories (Social Security Numbers, Government ID Numbers, Financial Account Codes, Credit or Debit Account Info). The notice summary says driver's licence numbers and banking information. These are consistent but not identical, and one claims page also lists categories, such as medical information, that its own article text does not mention. We report only the categories that appear in both the Vermont list and the notice summary, plus the Vermont list's own wording.

Open questions

• What the caller asked the employee to do. The answer decides which of the controls above would have mattered most.
• Which workloads were reached, and whether mail was read as well as files taken.
• Whether a new authentication method was registered, or whether a session was relayed.
• How many people were notified in total, and in which states.
• Whether any extortion demand was made. No source we read mentions one.

What would have helped

Nothing in this section claims to know what CSX had in place. These are controls that make a successful vishing call less useful to an intruder in any tenant.

Practices any team can use

• Phishing resistant sign in for the people callers target. Passkeys, FIDO2 keys, Windows Hello for Business or certificate based authentication, required through the Phishing-resistant MFA strength in Conditional Access. A relayed sign in page cannot use them.
• A Conditional Access policy on Register security information. This turns "add a new authenticator" into something that requires either a strong existing method or a verified Temporary Access Pass.
• A help desk runbook that never resets on a call alone. Call back on a number from HR records, or verify with Verified ID and Face Check before issuing a TAP.
• Alert on method registrations without tickets. The Authentication Methods audit activities give you the raw events; matching them to tickets turns them into a signal.
• Alert on bulk file access, and act on it within hours. CSX's alert fired. For any team, the question to rehearse is how quickly an alert on unusual file activity turns into a disabled account and revoked sessions.
• Keep audit records long enough to finish the review. File review in this incident ran 78 days after access ended. If your records age out at 180 days, export them on day one of any investigation.
• Put personal data where fewer accounts can reach it. Data minimisation shortens both the blast radius and the review.
• Teach the reverse rule to everyone. IT will never call and ask you to approve a prompt, read a code, or register a passkey on a link they send.

For a general incident template you can adapt, see our compromised dependency playbook. For how inventories speed up the "who is affected" question in software, see SBOM incident response. And for the month's wider picture, see October 2026 security incidents and what would have helped.

Where Safeguard fits

The boundary first, plainly. Safeguard's fit with this incident is indirect. Safeguard does not monitor Microsoft 365 sign ins, does not screen help desk calls, does not enforce Conditional Access and would not have detected or stopped a vishing call. Everything in the steps above happens in Microsoft's tools and in your help desk process.

Where Safeguard can help is around that core:

• Turning these controls into tracked evidence. Safeguard's Compliance suite (GA) maps controls and evidence to frameworks, with tabs for Controls, Evidence, Monitoring, Tests, Policies, Risks and Vendors, and connectors that collect evidence from cloud and identity providers. A help desk verification runbook, a phishing resistant MFA policy and a quarterly review of who can issue Temporary Access Passes are exactly the kind of controls that drift without an owner and a test. Recording them as controls with evidence makes the drift visible.
• Protecting the software supply chain that sits behind the same identity. Your source host, CI and registries trust the same sign in. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, results as JSON under ./output), shows which projects contain a given component and version, and evaluates policies and gates in the platform, so a change that reaches your build still has to pass review.
• Keeping a person on every action. The Safeguard CLI's assistant asks before it edits files or runs commands in its default modes (/permissions offers Ask, Accept edits, Plan, Auto and Strict), and the desktop and phone apps send work to a computer running the CLI where each command is approved or denied. That is the same principle as the help desk rule above: a request is not an approval.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh) is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. An artifact loses its badge if it regresses.

Neither applies to this incident. They are relevant to the rest of your estate, where the habit that matters is the same one this incident teaches for identity: do not trust a request just because it arrived, and pull from sources you can verify.

Common mistakes

• Treating number matching as phishing resistant. CISA places app based push with number matching below FIDO/WebAuthn and PKI. A person on the phone with a convincing caller can still be talked through it.
• Rolling out passkeys without locking registration. If anyone can register a new method from anywhere after a password and a push, an intruder can add their own passkey. Pair strong methods with the Register security information policy.
• Leaving Temporary Access Pass at multi use with long lifetimes. The default one time use setting is false. Decide deliberately, keep lifetimes short, and keep issuers few.
• Trusting the office network too much. A trusted location exclusion skips the registration check for anyone already inside it, including an intruder on a compromised device.
• Searching the audit log once, too early. Records typically take 60 to 90 minutes to appear. Search again later before you conclude.
• Forgetting the default result cap. Search-UnifiedAuditLog returns 100 records unless you page. Use -SessionCommand ReturnLargeSet and loop.
• Revoking sessions and stopping. Remove methods the user did not register, review inbox rules, and enrol the user again through a verified path.
• Waiting to export logs. If file review takes months, Audit (Standard) retention can run out before you finish.

FAQ

What happened in the CSX data breach?

According to CSX's notice as summarised in filings with state attorneys general, an employee responded to a vishing call on 29 May 2026, which let an unauthorized party into CSX's Microsoft 365 environment. Files were accessed and acquired until 9 June. CSX found on 26 August that some held personal information and began notifying people on 20 October.

What data was exposed?

The notice summaries list names with Social Security numbers, driver's licence numbers and banking information. Vermont's list records Social Security Numbers, Government ID Numbers, Financial Account Codes and Credit or Debit Account Info. Not every person had every field exposed.

How many people were affected?

No total has been published. Vermont lists 9 residents. A claims site reports at least 57 New Hampshire residents, which we could not confirm from the New Hampshire filing itself.

Was customer data exposed?

The notice summaries describe personal information about individuals in files, and a claims site says those individuals include current and former employees and third parties. One law firm headline said "customer data," but no source we could read supports that wording, so we do not use it.

Who was behind it?

CSX has not named anyone, and no primary source attributes the call. This post deliberately does not link it to any group. Vishing against Microsoft 365 has been reported from several clusters this year, and similarity of technique is not evidence of who called.

What is vishing?

Voice phishing: a phone call, sometimes with a cloned or spoofed voice or caller ID, that tries to get a person to reveal a credential, approve a sign in, or take an action that helps an intruder. Against Microsoft 365, the usual goals are a relayed sign in, an approved prompt, or a new authenticator added to the account.

Would MFA have stopped this?

It depends on the kind. A one time code or push approval can be relayed by a fake sign in page while a caller talks the person through it. Phishing resistant methods such as passkeys, FIDO2 keys, Windows Hello for Business and certificate based authentication are bound to the real site, which is why Microsoft and CISA both point to them.

What is the single most useful setting to change this week?

A Conditional Access policy on the Register security information user action, requiring a strong method or a verified Temporary Access Pass from outside trusted locations. It directly limits what a talked out password and approval can be turned into.

I got a CSX letter. What should I do?

Use the enrolment details and phone number printed on the letter for the free credit monitoring. Do not trust a call, text or email that claims to be about the letter; hang up and use the number on the letter. Consider a credit freeze with the three US credit bureaus and watch bank statements for unfamiliar activity.

How long does Microsoft 365 keep the audit records I would need?

Microsoft says Audit (Standard) keeps records 180 days for records created on or after 17 October 2023, and E5 class licences keep Entra ID, Exchange and SharePoint records for one year by default. Export what you need at the start of any investigation.

Fix it without waiting for upstream

This incident had nothing to patch, but most breaches that follow a stolen identity eventually reach code, builds and dependencies. The section below covers that side of your estate, where the fix usually is yours to ship.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows this incident, Microsoft 365 or a phone call. Each shows a real Safeguard flow built on the principle this incident tests: a request is not an approval, and a named person decides.

The first demo is a real Android session. Work is sent to a computer running the Safeguard CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. For a vishing story, the parallel is the out of band check: the approval happens on a device you hold, for an action you can read, rather than on someone's word over a call.

Click through it at your own pace, or open it full screen.

The second demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit; it ends with the upgrade done and tests passing. If an identity incident leads you to rotate tokens or bump dependencies across repositories, this is how you would do that work with every step visible and approved.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It is the same discipline as a locked down security info registration policy: access is granted on purpose, scoped to what is needed, and nothing more is assumed.

Click through it at your own pace, or open it full screen.

To try Safeguard on your own repositories, download Safeguard and follow the CLI docs.

Quick check

Sources

• Vermont Attorney General: Security Breach Notices (CSX entry, reported 20 October 2026)
• New Hampshire Department of Justice: CSX notice, 20 October 2026 (returned 403 to us; cited through the summaries below)
• ClaimDepot: CSX data breach exposed Social Security numbers
• ClaimDepot: CSX data breach investigation
• Microsoft Learn: Overview of Conditional Access authentication strengths
• Microsoft Learn: Control security information registration with Conditional Access
• Microsoft Learn: Configure a Temporary Access Pass
• Microsoft Learn: Verified helpdesk with Microsoft Entra Verified ID
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
• Microsoft Learn: Search the audit log
• Microsoft Learn: Audit log activities
• Microsoft Learn: Search-UnifiedAuditLog
• Microsoft Learn: Audit logs in Microsoft Entra ID
• Microsoft Learn: Microsoft Entra audit log activity reference
• CISA: Implementing Phishing-Resistant MFA (fact sheet)
• Help Net Security: IT help desk vishing tricks executives into handing over Microsoft 365 access (8 September 2026; context only, not linked to CSX)
• GlobeNewswire: law firm release on the CSX notice, 22 October 2026 (returned 403 to us; headline only)

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.