Two-factor authentication is the least glamorous security feature, and probably the most important one. A password is “something you know”, which really means “something that can be phished, reused, leaked, or guessed”. The second factor is “something you have”, and, while it can still be phished, it makes stolen passwords much less of a catastrophe they used to be. Everything else in account security is built on top of that. If the second factor is not there, or if it does not cover the data that actually matters, the rest is decoration.

Apple gets this right today. They did not always. The story of how they got here is worth telling, because it explains a lot about how iCloud acquisition works in 2026, and it leads directly to the two 2FA-related fixes in Elcomsoft Phone Breaker 11.03.

iCloud started with nothing

iCloud launched in 2011 with no second factor at all. Login and password, that was it. Two-step verification arrived in March 2013, and it came with two large asterisks. First, it was not available everywhere; it rolled out in a handful of countries and took years to reach the rest of the world. Second, and much more importantly, it protected the account, not the data. Two-step verification guarded your Apple ID settings and your iTunes purchases. It did not guard your iCloud backups. Anyone with your Apple ID and password could pull down a complete backup of your iPhone, and the second factor you had carefully switched on would never even be consulted.

You can guess how that ended.

Celebgate

In late summer 2014, a large collection of private photos belonging to celebrities appeared online. The press called it Celebgate. Apple investigated and stated there had been no breach of iCloud itself, and they were right: the accounts were compromised by phishing and by security questions that could be answered by anyone who had read the victim’s Facebook page. The passwords were simply handed over.

And then the passwords were enough, because backups were not behind the second factor. The tool used to convert those passwords into full account downloads was, in a number of cases, a pirated copy of ours. The U.S. Department of Justice names the software in the court filings for one of the convicted offenders: the defendant obtained complete iCloud backups belonging to more than 200 victims using, in the DOJ’s wording, software such as Elcomsoft. None of the people involved were customers of ours, and none of them were entitled to be. This is exactly why we sell to law enforcement and forensic labs and check who is on the other side of the transaction.

Apple extended two-step verification to iCloud data two weeks after the leak. Proper two-factor authentication followed in 2015 with iOS 9. Today, if you set up a new Apple Account, 2FA is on, and switching it off is not really an option any more.

Where things stand now

The second factor now covers everything worth covering, and one old shortcut is gone. Authentication tokens used to be a wonderful thing: extract a token from the user’s computer, and you could pull cloud data without a password and without a second factor. Apple has since pinned the tokens to the device that created them. Move the token somewhere else and it is a string of useless bytes. We removed token-based login from the product once this became consistent behavior, since offering a feature that fails silently is worse than not offering it. We are still poking at this, and if we find something workable, it will come back.

So a full login is required. Not counting passkeys, which we do not support, there are three ways to solve the 2FA challenge:

1. A code pushed to a trusted device. This is the preferred one: it is reliable, it is what Apple expects, and it is the least likely to upset anything on the server side.
2. An offline code generated on the trusted device itself, without any network connection. Handy when the device is in a Faraday bag, or when you would rather not have the phone talking to Apple. Apple moved this option in recent iOS versions and quite a few people assumed it was removed; it was not, and we wrote about where it went.
3. A code delivered by SMS to a trusted phone number. Works, but see below.

The trusted device is the real key

Here is the less obvious part. Year over year, the second factor has become more powerful than the password itself. If you have the trusted device and you know its passcode, but you do not know the account password, in most cases you can simply change the account password without knowing the old one. Sixty seconds, no password recovery, no iForgot, nothing. The second factor does not merely confirm the password; it can replace it.

The obvious caveat is Stolen Device Protection, which is now on by default. With SDP engaged, changing the Apple Account password from the device requires biometrics plus a one-hour security delay, and the web route at account.apple.com is closed off in the same way. Details are in Forensic Implications of Apple Stolen Device Protection. If cloud acquisition is your goal, plan for credentials and the second factor to come through lawful process rather than an on-device reset.

There is also a route through the SIM card and the trusted phone number, but it is slower, messier, and more conditional. We will leave it at that. We are deliberately not writing a step-by-step guide to “restoring” access to someone else’s account. Everything on this blog is aimed at legitimate forensic and law enforcement use, and the difference between a lab and a phishing crew should not be a matter of who read our blog more carefully.

What is fixed in Elcomsoft Phone Breaker 11.03

SMS-based 2FA works again. It had been broken for a good while, leaving trusted-device approval as the only working path, and experts were asking for it. It is back. We still recommend against it. SMS sign-in attempts carry a noticeably higher risk of the account being flagged or locked, and a locked account is of no use to anyone. If a trusted device is available, use the trusted device.

The pre-login 2FA check is gone. There used to be a way to ask Apple whether a given account had 2FA enabled, before signing in. It made sense in the days when plenty of accounts had no second factor and the check saved a step. It made much less sense once nearly every account except the very old ones had 2FA, at which point the check was answering a question with a foregone conclusion. The one remaining argument for it was that it did not raise a flag on the user’s devices, which was handy if an agency wanted to look at cloud data quietly. That argument was thin then, and it was uncomfortable in ways that go beyond engineering.

Apple has now closed the method entirely, and the way it closed produced the worst possible failure mode: the preliminary “check” login started failing, Phone Breaker reported the password as incorrect, and the attempt still lit up a notification on the user’s devices. Wrong on both counts, silently, in the one place where you least want surprises. So we removed the check-in login. Sign-in now goes straight to standard 2FA authentication.

Good riddance, honestly.