Sometime in early 2025, a setting on my iPhone stopped working. No email. No notification. No explanation. Advanced Data Protection, the option that extends end-to-end encryption across iCloud so that Apple cannot read additional categories of my data, had greyed out.
I had not chosen to change it. And unless you had gone looking, you might not have known anything had changed.
For a consumer, that is a privacy story. For a firm holding privileged or confidential client material, it raises a more useful question: who decides who can decrypt your data?
That is worth understanding properly, because professional firms now hold information across Microsoft 365, laptops, phones, backups and cloud services. Whether those systems are “encrypted” is only half the question.
The other half is who holds the keys.
What actually changed
In early 2025, reporting said the Home Office had served Apple with a Technical Capability Notice under the Investigatory Powers Act 2016, seeking access to data protected by Apple’s end-to-end encryption.
The notice itself is not public. The Home Office has declined to confirm or deny its details.
What Apple did next is public.
In February 2025, it withdrew Advanced Data Protection from new users in the UK, and told existing users the feature would not remain available to them either. New users could no longer enable it. Existing users who had already done so were told they would eventually need to disable the feature themselves to keep using their iCloud accounts.
Note the mechanism, because it matters.
Apple said it could not disable the feature automatically for existing users. With Advanced Data Protection enabled, Apple did not possess the keys needed to decrypt those additional categories of data.
The legal pressure could reach something Apple controlled: its ability to offer the feature. It could not simply give Apple encryption keys it had never held.
And that produced a perverse result.
Anyone who followed Apple’s guidance and switched Advanced Data Protection off could not switch it back on. Anyone who did not switch it off retained end-to-end encryption. Compliance was the losing move.
That is the part of the story worth remembering.
The encryption had not failed. The architecture had determined what was possible.
Apple says 15 categories of iCloud data remain end-to-end encrypted by default, including passwords in iCloud Keychain and Health data. iMessage and FaceTime also remain end-to-end encrypted. This is not a total collapse of iPhone security, and anyone presenting it that way is overstating the case.
But ten categories lost the option of Advanced Data Protection for UK users:
- iCloud Backup
- iCloud Drive
- Photos
- Notes
- Reminders
- Safari Bookmarks
- Siri Shortcuts
- Voice Memos
- Wallet Passes
- Freeform
iCloud Backup is the one professional firms should look at closely.
A fee earner does not need to deliberately save a privileged document into a personal iCloud Drive for business information to reach the cloud. Phones contain app data, downloaded documents, messages, photographs, screenshots and cached information. Backups can create copies that neither the fee earner nor the managing partner consciously considered.
That turns a consumer setting into an information-governance question.
The number worth sitting with
Apple publishes transparency reports showing government requests for customer data.
For January to June 2024, the UK submitted 2,550 account requests covering 2,920 account identifiers. Apple provided some form of data in response to 82% of them.
That is roughly fourteen account requests every day, weekends included, for six months.
Measured against population, the UK request rate was close to that of the United States and far higher than mainland China’s. The US submitted 12,812 account requests and mainland China 398 during the same period, but both have considerably larger populations.
Now be precise about what that 82% represents, because the imprecise version is easy to dismiss and the precise version is far more interesting.
An account request is not necessarily a request for the contents of an iCloud account. One request can cover several accounts. Apple’s category includes account information such as the account holder’s details and connections to Apple services, as well as requests that may seek stored content such as photos, email, device backups, contacts or calendars.
In practice, the UK figure was overwhelmingly non-content. Apple’s detailed table records 2,090 requests where only non-content data was provided and just two where content was provided.
Content requests made under the US-UK Data Access Agreement are reported separately. For the same reporting period, Apple records 500-999 UK requests for content under that agreement. The exact number is not publicly available: Apple is legally required to delay reporting by six months and publish the figures in bands of 500.
Set those two figures beside each other.
Through the ordinary account-request route, content was provided twice. Through the Data Access Agreement route, UK authorities made between 500 and 999 requests for content in the same six months. Apple’s published table does not state how many of those requests resulted in content being disclosed.
So the honest position is not that British authorities were reading fourteen people’s iCloud backups every day. They were not, and anyone claiming otherwise is easy to discredit.
But the demand for content is not marginal. Apple’s own figures show hundreds of content requests through the bilateral agreement route in six months, alongside the much larger volume of ordinary account requests.
Advanced Data Protection never stopped a single request arriving. It changed what Apple could produce in readable form.
And that is what makes the reported Technical Capability Notice significant. The precise operational objective remains secret, but reporting indicates that the notice sought to change Apple’s technical ability to provide access to data protected by Advanced Data Protection.
The notice did not need to create a government-request pipeline. One already existed.
It sought to change what Apple was technically capable of supplying through it.
That is the reason this matters to a firm rather than only to a privacy campaigner. The protection that was withdrawn was not theoretical. It changed who possessed the technical capability to decrypt the data.
Why the secrecy matters
There is another lesson here for firms.
The public did not learn about the reported notice because the Home Office published it or Apple explained it to customers. The legal framework around Technical Capability Notices restricts disclosure, and much of what became public emerged through reporting and subsequent litigation.
That matters because a managing partner might reasonably assume that if something materially changed the confidentiality model of a major cloud service, the firm would know.
You cannot safely build information governance on that assumption.
This is not an argument that technology providers are untrustworthy. It is an argument for understanding what they are technically capable of doing with your data.
There is a difference between:
“The provider is restricted from accessing this information.”
and:
“The provider does not possess the key required to decrypt this information.”
Both can be useful protections. They are not the same protection.
What this means for a firm holding privileged material
Your duty to protect confidential client information does not contain an exception for storage arrangements nobody thought to review.
For solicitors, the issue is particularly obvious because of client confidentiality and legal privilege. The same principle applies to accountants holding financial and tax records, financial firms handling sensitive client information, and architects working with confidential project material.
GDPR also takes a risk-based approach to security. The relevant question is not whether every file requires the strongest encryption technology available. It plainly does not.
The question is whether the protection is appropriate to the information and whether somebody made that decision deliberately.
That brings us back to the key.
With ordinary provider-managed encryption, your cloud provider may hold what it needs to decrypt the data. That arrangement enables useful things: recovery, search, browser-based editing, compliance tools and collaboration.
For most business information, that may be entirely appropriate.
But if a small category of information is so sensitive that the provider itself should not be capable of decrypting it, you need a different architecture.
Microsoft 365 is not automatically the answer
Many professional firms will read the Apple story and conclude they are fine because they are a Microsoft house.
Test that assumption.
Microsoft 365 provides strong encryption and security controls. A properly managed Microsoft 365 environment is also very different from staff scattering client files across unmanaged personal cloud accounts.
But “Microsoft encrypts our data” still does not answer the key question.
Customer Lockbox is a good example.
It is often described as though it gives your firm approval over Microsoft accessing your data. More precisely, it inserts the customer into the approval process when Microsoft personnel require access to customer content for certain service operations.
That is useful.
It does not apply to external legal demands.
Microsoft says so explicitly: Customer Lockbox does not protect against data requests from law-enforcement agencies or other third parties. Those requests follow a separate process.
So Lockbox answers:
Can Microsoft support personnel access our content through this operational route?
It does not answer:
Does Microsoft possess what is technically required to decrypt this document?
For particularly sensitive information, Microsoft offers a different control.
Double Key Encryption
Microsoft Purview Double Key Encryption uses two keys. Microsoft controls one; your organisation controls the other.
Both are required to decrypt protected information.
That changes the architecture. Microsoft does not independently hold everything required to decrypt the file.
But there is a cost to that control, and it is not merely financial.
Cloud services can only search, inspect and collaborate on information they can process. Protect information from the provider strongly enough and you also remove some of the provider’s useful capabilities.
There is a licensing consideration too. DKE requires qualifying Microsoft 365 licensing, such as Microsoft 365 E5, or Microsoft 365 E3 with the relevant E5 Compliance add-on. It is not a capability you simply switch on in the Business Premium environment many smaller professional firms use.
That is why Double Key Encryption is not something we would recommend applying across an entire Microsoft 365 tenant.
It is a specialist control for a labelled subset of genuinely sensitive material where the confidentiality requirement justifies the additional licensing, administration and loss of cloud functionality.
The important distinction is not Apple versus Microsoft.
It is provider-held keys versus customer-controlled keys.
Three questions worth asking whoever runs your IT
You do not need to understand cryptography to act on any of this.
Ask three questions.
1. Where does privileged client material actually live, including on mobile devices and in device backups?
Do not stop at SharePoint, your document-management system or your case-management platform. Follow the information onto phones, laptops, SaaS applications and backups.
2. For each of those locations, who holds the key?
If the answer is buried under phrases such as “enterprise-grade encryption” or “AES-256”, ask again. Those describe aspects of encryption. They do not tell you who can decrypt the data.
3. If the answer is “the provider”, was that a decision anyone made, or a default nobody looked at?
That is the governance question.
There is nothing automatically wrong with a provider holding encryption keys. In many cases, it is the right balance between security and usability.
But your most sensitive client information should not sit under that model simply because nobody asked.
The principle underneath all of this
The argument around Advanced Data Protection involves difficult questions about privacy, serious crime, national security and the powers governments should have over technology companies.
Professional firms do not need to settle that argument.
The useful lesson is architectural.
Apple’s encryption did not fail. Apple retained the ability to stop offering Advanced Data Protection in one market, but it could not automatically switch off protection for users whose devices held the keys.
That is a very different situation from a cloud service where the provider possesses everything required to decrypt the customer’s data.
And it gives firms a principle that survives changes in governments, policies and technology vendors:
If the provider holds the keys, the provider can potentially be compelled to use or produce what it controls. If a necessary key remains under the customer’s independent control, the provider cannot produce a key it never had.
That does not mean every document needs customer-controlled encryption.
It means the decision should belong to your firm.
Not to a default.
Not to an assumption.
And not to a cloud configuration nobody knew had changed.
Know where the data is and who holds the key
The greyed-out setting on an iPhone is the hook. The professional question underneath it is much more important.
Where does your confidential client information actually live?
Who can decrypt it?
And did your firm deliberately choose that arrangement?
If you cannot answer those three questions, that is a useful gap to find.
INNOSEC’s Microsoft 365 Security Assessment reviews how sensitive information moves through Microsoft 365, endpoints and mobile devices, and where security defaults may not match the confidentiality of the data you hold.
No blanket recommendation to encrypt everything twice. No security theatre.
Just a clear answer to the question that matters: who holds the key?
Related: Cybersecurity services for professional firms
Find out where your IT stands
Book a free 15-minute call. If it’s a fit, the next step is our IT Risk and Ownership Review: £295 + VAT, using read-only access to your Microsoft 365, and credited against your first month.
