The 2011 RSA SecurID Breach: When the Security Vendor Was Hacked

In March 2011, RSA, the security division of EMC, announced something that unsettled the security industry. The company that sold the SecurID tokens used by banks, governments and defence firms to protect logins had itself been breached. The incident became a case study in how a single phishing email can reach deep into a well-defended company, and in why no security product should be treated as invincible.

What RSA disclosed

On 17 March 2011, RSA's executive chairman Art Coviello published an open letter to customers. He said the company had identified an extremely sophisticated cyberattack in progress and that information related to its SecurID two-factor authentication products had been extracted. RSA did not initially say exactly what had been taken, which led to speculation, and it advised customers to strengthen their own security practices.

SecurID tokens display a number that changes every minute or so, based on a secret value stored in the token and on RSA's servers. If the underlying secrets were stolen, an attacker would still need other information, such as the user's password, to make use of them. But the incident made customers question how much trust to place in tokens whose manufacturer had been compromised.

How the attackers got in

RSA described the entry point later in a blog post. Two small groups of employees received a spreadsheet by email titled "2011 Recruitment plan". At least one employee retrieved the message from a junk folder and opened it. The spreadsheet contained an embedded Flash object that exploited a zero-day vulnerability in Adobe Flash Player, installing a remote-access tool. From there, the attackers worked their way to more valuable systems and moved data out.

The important detail is how ordinary the first step was. A believable subject line, a document that seemed work-related and a software flaw were enough.

The fallout

In June 2011, RSA offered to replace SecurID tokens or provide security monitoring services for its customers, after reports that the defence contractor Lockheed Martin had experienced an attack in May that was connected to the earlier breach. Lockheed said it had detected the attempt and that no customer, programme or employee data had been compromised. RSA's parent company reported significant costs for responding to the incident.

What the incident revealed

• Vendors are targets. Attackers go after the companies that supply security, because they open doors to many customers at once.
• Hardware tokens are not the end of the story. Even strong authentication can be weakened if its secrets leak.
• User behaviour matters. The first domino was an email opened by an employee.
• Disclosure shapes trust. Customers needed clear information quickly and were frustrated by how little they initially got.

Two-factor authentication still matters

It would be the wrong conclusion to decide that two-factor authentication is pointless. For ordinary website owners, it remains one of the most effective ways to stop password theft from becoming account takeover. The point of the RSA story is that it is one layer. Combine it with strong unique passwords, limited privileges and monitoring, so that a failure in any single control does not become a disaster.

It is also a reminder to look at your own suppliers. Your hosting panel, domain registrar, email provider and the plugins on your site all hold keys to your business. If one of them is compromised, you want to find out quickly and to have a plan: which passwords to change, which tokens to revoke and who to tell.

What changed afterwards

The breach prompted many organisations to rethink how they used authentication. Some moved away from relying on a single token vendor, and some added extra checks for high-risk actions rather than trusting a code alone. The industry also paid more attention to how secret values are generated, stored and protected, since the value of any token depends on the secrecy of what sits behind it.

It also changed how security companies talk to customers. RSA's first statement was criticised for being vague, and later incidents involving other vendors showed that people expect fast, specific advice on what to do. If you ever have to tell your own customers that something has gone wrong, that expectation applies to you too: say what you know, say what you do not know yet, and tell people which steps to take.

The practical lesson for site owners

Turn on two-factor authentication for every account that can change your website: your hosting panel, domain registrar, email, CMS administrators and any payment or analytics service. Use an authenticator app or hardware key where possible, store recovery codes safely, and train everyone with access to be cautious with unexpected attachments, even ones that look relevant to their job.

Our security page describes what is available on our hosting plans, and our knowledge base has guides for securing your control panel login.