What Was the RSA SecurID Breach? The Token Was Never Broken

September 2, 2026

The email was one sentence long.

I forward this file to you for review.

Subject line: 2011 Recruitment Plan. Attached: a spreadsheet called 2011 Recruitment plan.xls. It went out on 3 March 2011, to two small groups of employees at EMC, RSA's parent company. None of them were executives or administrators.

It was caught by the spam filter. Someone went into junk and got it out.

That last detail has been used for fifteen years as a lesson about user awareness, which is a misreading of the incident so complete that it hides what actually went wrong.

What was the RSA SecurID breach?

In March 2011, intruders got into the network of RSA, the security division of EMC, and extracted information relating to SecurID — at that time the dominant hardware two-factor authentication product, in the hands of defence contractors, banks, and government departments worldwide.

RSA disclosed the intrusion on 17 March 2011 in an open letter, without saying precisely what had been taken. In May, Lockheed Martin detected an intrusion on its own network. RSA subsequently confirmed that information taken from it had been used in that attack.

The chain from a spreadsheet to a defence contractor took about eleven weeks.

The attachment

Inside the spreadsheet was an embedded Adobe Flash object exploiting CVE-2011-0609 — a zero-day on the day it arrived, patched by Adobe on 21 March.

That combination deserves a moment. Excel would happily render an embedded Flash object, which meant Flash's attack surface was reachable through an email attachment that looked like a spreadsheet, on a machine where nobody had opened a browser. Two products, each behaving as documented, composing into something neither team had signed off.

The exploit installed a remote access tool — reporting at the time identified it as Poison Ivy, a widely available RAT rather than anything bespoke. From that one workstation the intruders escalated, moved to accounts with more access, staged data internally, and moved it out.

The tooling was ordinary throughout. That is worth sitting with, given that the target was a company whose entire business was authentication.

The junk folder, and why the lesson is wrong

Here is the sentence that launched a thousand awareness slides: the spam filter caught it, and an employee retrieved it and opened it anyway.

Consider what that person was doing. It is March. A file called 2011 Recruitment Plan is in the junk folder. Filters misfile internal-looking mail constantly — anyone who has waited on an invoice knows the junk folder is a place you go and look. Retrieving a plausibly-legitimate business document from junk is not negligence. It is the job.

Blaming that keystroke requires you to believe the security of a global authentication system should rest on one person's judgement about one email, on one Thursday, against a zero-day.

The filter worked. It flagged it. And the design still failed, because a single workstation opening a single file was sufficient to begin a path that ended at the seed records. The interesting failures are all downstream of that click, and none of them are the click.

What a seed actually is

This is the part that makes the incident make sense.

A SecurID token is not clever and it is not supposed to be. Inside it is a seed — a secret value burned in at manufacture — and a clock. The token runs a known algorithm over the seed and the current time and displays the result. The authentication server, holding the same seed and the same clock, computes the same number and compares.

There is no secret in the algorithm. The security rests entirely on the seed remaining known only to the token and the server.

So: who has the seeds? The customer's server does. And the manufacturer does, because the manufacturer generated them, loaded them into the hardware, and shipped a seed file to the customer alongside the tokens. That is not a lapse, it is how the product worked.

Which makes RSA's own network the single point at which the security of every SecurID deployment on earth converged. Not the tokens — the tokens were fine. The list.

Reporting on the Lockheed attack indicated that the attackers possessed seed values, token serial numbers and the underlying algorithm. With those three, plus knowledge of which serial number sits on which person's desk, the second factor stops being a second factor.

Lockheed Martin

Lockheed detected the intrusion on 21 May 2011 and moved fast: remote access shut off, new tokens issued, and all 133,000 employees made to reset their network passwords.

Lockheed's own account, which is the part of this story worth teaching, is that its response worked because it did not treat the token as the wall. It had internal monitoring that noticed anomalous behaviour from valid credentials — the reasoning that became its published kill chain model. A valid one-time code from a valid token, doing something a person would not do, was still visible.

That is the difference between an organisation that authenticates and an organisation that watches.

The $66.3 million figure

EMC took a $66.3 million charge against second-quarter 2011 earnings for the response. It is a real audited number rather than an estimate of damages, which makes it more useful than most breach figures — and it is worth knowing what it bought.

It covered the investigation, hardening of EMC's own systems, transaction monitoring for anxious customers, and token replacement — but not universal token replacement. RSA offered new tokens to roughly the one-third of its customer base using SecurID to protect intellectual property and corporate networks. For the remaining two-thirds, largely consumer banking deployments, it offered additional monitoring instead.

So the widely repeated shorthand that RSA replaced forty million tokens is not right. Forty million is roughly the number in circulation. The replacement programme was triaged by what the tokens were guarding.

What changed afterwards

The seed-distribution model was the thing that had to move, and it did. The industry shifted toward schemes where the verifier does not hold a shared secret at all — public-key based authenticators, where the private key never leaves the device and there is no central list to steal. The straight line from this incident runs to U2F and then to FIDO2 and passkeys.

The other change is cultural, and slower. RSA's disclosure was criticised at the time for being vague, and the criticism was fair. But it disclosed, promptly, that its own flagship security product had been compromised — and the eleven-week gap to Lockheed is the argument for having done so.

EXHIBIT 0023 — RSA SECURID

We put it on a shirt. A woven metal office wastebasket, drawn as an engraving, full of crumpled paper — and a hand reaching in to lift one clean sealed envelope back out of it. On the envelope: 2011 Recruitment plan.xls.

No token, no keyfob, no six digits. The token was never the story. The callouts run THE FILTER CAUGHT IT, IT WAS RETRIEVED FROM JUNK, FLASH OBJECT INSIDE A SPREADSHEET, SEED RECORDS AND SERIAL NUMBERS, and the line across the bottom settles it: the filter worked. That was never the problem.

That's the whole idea.

View the RSA SecurID shirt — EXHIBIT 0023

Back to blog

Item added to your cart