“Permanent and Necessary” — Microsoft’s Response to a Hacked Account
On August 11, 2026, streamer Joshua Hein posted a thread on X that spread across tech communities with unusual speed. A hacker had broken into his Microsoft account, changed every security setting, and locked him out. Twenty-five years of files — personal photos, emails, OneDrive documents including baby pictures of his son — were now completely inaccessible.
Microsoft’s support team confirmed the account was his. Then they told him the recovery was impossible. The company’s internal policy categorizes any account where security settings have been changed after a compromise as “permanently locked” to prevent further abuse.
The story had a partial happy ending: after widespread media coverage, Microsoft eventually reversed its position and restored access. But the episode exposed something that millions of cloud storage users have never seriously considered. A data breach at a company is one category of threat. A hostile takeover of your personal account — by an external attacker — is an entirely different one, and most people have no plan for it.
The Difference Between a Breach and a Hijack
Most cloud storage security coverage focuses on the provider side: a company’s servers get hacked, data is exfiltrated, users receive a breach notification email. These are real and consequential events.
Account hijacking is different in a fundamental way. Here, the attacker doesn’t need to break the company’s systems at all. They break into you — through a reused password, a phishing attack that captures your credentials, a SIM-swap attack against your phone number, or malware running on your device. Once they’re in, they act as you. They change the recovery email. They disable your two-factor authentication. They register their own authentication devices. By the time you notice something is wrong, the system treats you as the intruder.
This is not a theoretical risk in 2026. According to IBM’s Cost of a Data Breach Report, compromised credentials remain the leading initial attack vector for cloud-related incidents year after year. The same credential packages sold on dark web marketplaces — login address, password, sometimes matched against a real identity — can give an attacker what they need to take over a Microsoft, Google, or iCloud account in minutes.
The breach here isn’t at the cloud provider. It’s at you.
What You Actually Lose When an Account Gets Hijacked
The Hein case is instructive because the loss was not abstract. It included:
- Family photos stored in OneDrive, including images of his young son that existed nowhere else
- Game purchases worth thousands of euros, tied permanently to his Xbox account and inaccessible without it
- Years of email history — personal and professional correspondence
- Access to every downstream service that used his Microsoft account as a login method
When your identity at a cloud provider is effectively destroyed — which is what a full credential takeover accomplishes — you lose access to everything tethered to that identity. It doesn’t matter that you paid for the storage. It doesn’t matter that the files legally belong to you. The keys to the lock no longer recognize you.
The Recovery Paradox
Here’s the structural problem at the core of this: the same policies that make cloud providers hard for attackers to access after a hijack also make them hard for victims to reclaim. The attacker changes all the verification checkpoints. When you try to use those same checkpoints to prove you’re you, they now point at the attacker’s phone number and email address.
Microsoft’s original position — that changed security settings after a compromise make recovery “impossible” — is coherent from an engineering standpoint. The provider has no reliable automated mechanism to distinguish between the genuine account owner claiming “my account was hijacked, restore me” and the hijacker trying to maintain access by claiming their victim is the real attacker.
This structural limitation is not Microsoft-specific. Google, Apple, Dropbox, and every major cloud service faces the same underlying challenge. The verification infrastructure is built around credentials, and credentials can be changed.
The human escalation path — talking to a person, providing documentation, escalating to a manager — is exactly what eventually worked for Hein. But it required his case attracting media attention before Microsoft acted. Without public pressure, the outcome may have been different.
Why Cloud Storage Alone Is a Single Point of Failure
Hein explicitly noted that he had made no backup copies of the files and purchased content tied to his account. That’s the underlying vulnerability: when cloud storage is your only copy, a cloud access problem immediately becomes a data loss problem.
This applies to far more situations than account hijacking:
Providers can suspend or delete accounts for terms of service violations, even erroneous ones — automated systems flag legitimate content incorrectly with some regularity, and the appeals process is rarely fast.
Providers can go bankrupt, especially smaller storage services with thinner margins. Several have done so in the past few years.
Providers can change pricing or access tiers, effectively holding your data until you pay more.
Outages occur, and while rare with major providers, even brief outages can cost access at critical moments.
The 3-2-1 backup rule exists for exactly this reason: three copies of any important data, across two different types of media, with one copy stored offsite or independently of your primary storage provider. Cloud storage is one of those copies. It should not be all three.
Understanding Account Takeover: How It Actually Happens
Most account hijackings follow a small number of attack patterns. Understanding them makes protection more concrete.
Credential stuffing. When another website or service suffers a breach, your username and password from that site get sold or leaked. If you used the same password on your cloud storage account, an attacker can try it and get in. This works at scale because password reuse is extremely common.
Phishing. You receive an email that looks like a security alert from Microsoft, Google, or Apple. The link goes to a convincing copy of the real login page. You enter your credentials, the site captures them, you get redirected to the real service. The attacker now has your password, potentially plus a one-time code if the phishing page proxies your session in real time.
SIM swapping. The attacker contacts your mobile carrier and convinces them to transfer your phone number to a SIM card they control. If your cloud account uses your phone number for two-factor authentication or account recovery, the attacker now controls that factor and can receive the verification codes.
Malware. A keylogger or credential-harvesting malware on your device captures your cloud storage password as you type it or extracts saved credentials from your browser.
Steps to Protect Yourself Before It Happens
Use a unique, strong password for every cloud service. Credential stuffing attacks only work because of password reuse. A password manager — Bitwarden, 1Password, or another reputable option — generates and stores unique passwords for every account. This single step eliminates the most common attack vector.
Enable the strongest available form of multi-factor authentication. Hardware security keys that implement the FIDO2 standard are the most resistant to both phishing and SIM-swapping, because they verify the domain you’re logging into. Authenticator apps generating time-based codes (TOTP) are the second-best option. SMS codes, while better than nothing, are vulnerable to SIM-swap attacks.
Set up account recovery options now, while you have full access. For Microsoft accounts, this means setting up a recovery code and verifying backup contact methods. For Google accounts, ensure your recovery email and phone number are current and verified. Do this before you need it — after a takeover, it may be too late.
Use a different email address as your account recovery contact than the one associated with the account being protected. An attacker who controls your primary email address can use account recovery flows against you.
Know what your provider’s lockout appeal process looks like. Some providers have documented escalation paths for identity disputes after a hijacking. Others have minimal public documentation. Understanding this before you need it shapes how aggressively you should maintain independent backups.
Maintain at least one independent copy of irreplaceable files. Personal photographs of family, legal documents, medical records, financial records — none of these belong solely in a single cloud account. An external hard drive, a home NAS device, a second cloud provider under a different account, or a privacy-focused personal storage service with its own independent credentials all provide options.
The Hidden Assumption Cloud Storage Sells You
The marketing around cloud storage bundles together genuine benefits — automatic backup, multi-device access, disaster protection from local hardware failure — with an implicit assumption that deserves scrutiny: that you remain in continuous, uncontested control of your account identity.
When that assumption holds, cloud storage delivers on its promise. When it breaks — when an attacker reconstructs your account identity before you can respond — the same infrastructure protecting your data now protects it from you.
This is a structural tension, not a flaw unique to any particular provider. It’s worth understanding before you decide how much to rely on any single cloud account for data you can’t afford to lose.
What to Look For in Storage You Trust
A cloud service worth trusting with sensitive personal files should be transparent about a few specific things:
Account recovery procedures. What escalation paths exist if you lose access? How long does dispute resolution take, and what documentation is required?
Deletion behavior. If your account is closed — by you, by the provider, or by a successful attacker — how long before data is permanently erased? Some services delete immediately; others maintain a grace window during which the account can be restored.
Encryption at rest. Are your files stored in a form that would be meaningless to an attacker who accessed the storage infrastructure directly?
Independence from linked services. Does losing access to one linked account cascade into losing access to your storage? Accounts that authenticate via a third-party identity provider inherit all of that provider’s vulnerability surface.
daftei uses AES-256 encryption at rest and TLS 1.3 in transit. When an account is deleted, there is a 30-day grace window before erasure becomes permanent and irreversible. This means an attacker who forces account deletion cannot make that deletion instant — you retain a window during which the account can potentially be recovered through legitimate channels.
The right response to stories like Hein’s is not to avoid cloud storage. It’s to stop treating any single cloud account as your only copy of anything irreplaceable, and to understand the difference between having access to your files and owning them.