Apple Platform Security (Jan 2026) [pdf]

https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf

by pieterr • 6 months ago

224 176 6 months ago

help.apple.com

OGEnthusiast3• 6 months ago

Glad there's still at least one tech company that cares about personal security / opsec.

varispeed5• 6 months ago

No mention of Pegasus and other software of such sort. Can latest iOS still be infected?

There is no point creating such document if elephant in the room is not addressed.

gjsman-1000• 6 months ago

Why? The obvious conclusion is that Apple is doing everything in its power to make the answer “no.”

You might as well enumerate all the viruses ever made on Windows, point to them, and then ask why Microsoft isn’t proving they’ve shut them all down yet in their documents.

varispeed5• 6 months ago

That analogy misses the asymmetry in claims and power.

Microsoft does not sell Windows as a sealed, uncompromisable appliance. It assumes a hostile environment, acknowledges malware exists, and provides users and third parties with inspection, detection, and remediation tools. Compromise is part of the model.

Apple’s model is the opposite. iOS is explicitly marketed as secure because it forbids inspection, sideloading, and user control. The promise is not “we reduce risk”, it’s “this class of risk is structurally eliminated”. That makes omissions meaningful.

So when a document titled Apple Platform Security avoids acknowledging Pegasus-class attacks at all, it isn’t comparable to Microsoft not listing every Windows virus. These are not hypothetical threats. They are documented, deployed, and explicitly designed to bypass the very mechanisms Apple presents as definitive.

If Apple believes this class of attack is no longer viable, that’s worth stating. If it remains viable, that also matters, because users have no independent way to assess compromise. A vague notification that Apple “suspects” something, with no tooling or verification path, is not equivalent to a transparent security model.

The issue is not that Apple failed to enumerate exploits. It’s that the platform’s credibility rests on an absolute security narrative, while quietly excluding the one threat model that contradicts it. In other words Apple's model is good old security by obscurity.

Retr0id3• 6 months ago

don't worry, they set the allow_pegasus boolean to false

goalieca2• 6 months ago

Apple did create a boolean for that. They call it lockdown mode.

Lockdown Mode is an optional, extreme protection that’s designed for the very few individuals who, because of who they are or what they do, might be personally targeted by some of the most sophisticated digital threats. Most people are never targeted by attacks of this nature. When Lockdown Mode is enabled, your device won’t function like it typically does. To reduce the attack surface that potentially could be exploited by highly targeted mercenary spyware, certain apps, websites, and features are strictly limited for security and some experiences might not be available at all.

wat10000• 6 months ago

Pegasus isn't magic. It exploits security vulnerabilities just like everything else. Mitigating and fixing those vulnerabilities is a major part of this document.

jesseendahl2• 6 months ago

Apple's head of SEAR (Security Engineering & Architecture) just gave the keynote at HEXACON, a conference attended by the companies who make Pegasus such as NSO Group.

That doesn't seem like avoiding the elephant in the room to me. It seems like very much acknowledging the issue and speaking on it head-on.

https://www.youtube.com/watch?v=Du8BbJg2Pj4

random_duck• 6 months ago

Wow, this is hardcore (pun intended).

buildbot• 6 months ago

262 pages!!! Pretty interesting to see how the different SoCs have evolved security wise over time.

easton2• 6 months ago

Web version: https://support.apple.com/guide/security/welcome/web

sonu27• 6 months ago

That’s Dec 2024

easton2• 6 months ago

Weird. On my end it says January 2026.

whitepoplar• 6 months ago

Given that A19 + M5 processors with MIE (EMTE) were only recently introduced, I wonder how extensively MacOS/iOS make use of the hardware features. Is it something that's going to take several years to see the benefit, or does MIE provide thorough protection today?

bri3d2• 6 months ago

I think all of the kernel allocators and most (?) system processes in iOS 26 have MIE enabled, as does libpas (the WebKit allocator), so it’s already doing quite a lot.

armadyl2• 6 months ago

I was just watching a video on this yesterday: https://www.youtube.com/watch?v=5McB6-2r-ds

Apple’s implementation of MTE is relatively limited in scope compared to GrapheneOS (and even stock Android with advanced security enabled) as it’s hardware intensive and degrades performance. I imagine once things get fast enough we could see synchronous MTE enabled everywhere.

It is curious at the moment though that enabling something like Lockdown Mode doesn’t force MTE everywhere, which imo it should. I think the people who are willing to accept the compromises of enabling that would likely also be willing to tolerate the app crashes, worse performance etc that would come with globally enabled MTE.

drnick1• 6 months ago

But all the software is closed source, and there is little to no opportunity to verify all these security claims. You don't have the encryption keys, so effectively the data is not under your control.

If you want to see security done well (or at least better), see the GrapheneOS project.

digiown5• 6 months ago

GrapheneOS also doesn't give you the encryption keys. If you run the official version, there is no way for you to extract the data from your device at all beyond what app developers will let you access. This means that you do not own the data on your device. The backups are even less effective than Apple's, although they say they will work on it.

The developers also appear to believe that the apps have a right to inspect the trustworthiness of the user's device, by offering to support apps that would trust their keys [1], locking out users who maintain their freedom by building their own forks.

It's disheartening that a lot of security-minded people seem to be fixated on the "AOSP security model", without realizing or ignoring the fact that a lot of that security is aimed at protecting the apps from the users, not the other way around. App sandboxing is great, but I should still be able to see the app data, even if via an inconvenient method such as the adb shell.

1. https://grapheneos.org/articles/attestation-compatibility-gu...

zb33• 6 months ago

For some reason they don't release userdebug versions which was a dealbreaker for me.. (the device should be secure, but not against me)

But if you wish to build it from source, it could probably be a good option.

armadyl2• 6 months ago

The developers also appear to believe that the apps have a right to inspect the trustworthiness of the user's device, by offering to support apps that would trust their keys [1], locking out users who maintain their freedom by building their own forks.

That is not a bad thing. The alternative is not having apps that do these checks available on the platform at all. It’s ridiculous that someone should expect that every fork of it should have that capability (because the average developer is not going to accept the keys of someone’s one off fork).

If there’s anyone to blame, it should be the app developers choosing to do that (benefits of attestation aside).

Attestation is also a security feature, which is one of the points of GOS. People are free to use any other distribution of Android if they take issue with it.

Obviously I could be wrong here, this is just the general sentiment that I get from reading GOS documentation and its developer’s comments.

surajrmal3• 6 months ago

You were not going to be able to use those apps anyways, so what does it matter to you? I, and I suspect many, agree with the purpose of attestation. The problems around it are strictly around establishing good ways to teach apps who they should trust, not around attestation itself. By putting your head in the sand, you'll never improve the situation.

amelius2• 6 months ago

Yes, how can we verify this? Who says three-letter agencies have no access?

daneel_w• 6 months ago

We can't verify that the Pixel phones are safe. Nor can the GrapheneOS people, because they don't know everything that's running in the Google Tensor SoC, and they don't have the source code to the firmware running in the Samsung Exynos cellular modem.

rrgok• 6 months ago

Sometime I wonder how much overhead all these security features take in terms of performance.

I would really like to see a benchmark with and without security measures.

Retr0id3• 6 months ago

It's not really possible to make a direct comparison, given that a big chunk of the features are baked into the silicon, or are architecture-level choices.

TheNewsIsHere• 6 months ago

It’s technically possible, but it would be difficult and likely require breaching an NDA. A bit pedantic, perhaps, but it’s out there.

Apple makes available on a highly controlled basis iPhones which permit the user to disable “virtually all” of the security features. They’re available only to vetted security researchers who apply for one, often under some kind of sponsorship, and they’re designed to obviously announce what they are. For example they are engraved on the sides with “Confidential and Proprietary. Property of Apple”.

They’re loaned, not sold or given, remain Apple’s property, and are provided on a 12-month (optionally renewable) basis. You have to apply and be selected by Apple to receive one, and you have to agree to some (understandable but) onerous requirements laid out in an legal agreement.

I expect that if you were to interrogate these iPhones they would report that the CPU fuse state isn’t “Production” like the models that are sold.

They refer to these iPhones as Security Research Devices, or SRDs.

relium• 6 months ago

The ones I remember most affecting performance were zeroing allocated memory and the Spectre/Meltdown fix. Also, the first launch of a new app is slow in order to check the signature. Whole disk encryption is pretty fast today, but probably is a bit slower than unencrypted. The original FileVault using disk images was even slower.

mcculley• 6 months ago

Whole disk encryption is pretty fast today, but probably is a bit slower than unencrypted.

Isn’t whole disk encryption nowadays done in hardware on the storage controller?

astrange2• 6 months ago

It's not whole-disk encryption, it's file-level encryption which is better. (more security guarantees)

Zeroing allocated memory is complicated because it also has performance benefits, since it improves compressed swap.

zb33• 6 months ago

Protects the device well... against the owner of the device using it as they wish :)

wcfrobert• 6 months ago

Apple's commitment to privacy and security is really cool to see. It's also an amazing strategic play that they are uniquely in the position to take advantage of. Google and Meta can't commit to privacy because they need to show you ads, whereas Apple feels more like a hardware company to me.

bigyabai6• 6 months ago

You know what's even cooler? Apple's commitment to hiding US federally-mandated backdoors for dragnet surveillance: https://arstechnica.com/tech-policy/2023/12/apple-admits-to-...

  Apple has since confirmed in a statement provided to Ars that the US federal government “prohibited” the company “from sharing any information,” but now that Wyden has outed the feds, Apple has updated its transparency reporting and will “detail these kinds of requests” in a separate section on push notifications in its next report.

Noaidi2• 6 months ago

That people fall for this corporate BS while Tim Cook is giving gold bars to Trump and dining and dancing with him When people are being murdered on the streets by ice is just amazing to me.

OGEnthusiast3• 6 months ago

Well that’s what Americans voted for. So I don’t think anyone cares that every CEO (definitely not just Tim Cook) is schmoozing with Trump.

jtbayly2• 6 months ago

modeless linked to this article earlier today:

https://james.darpinian.com/blog/apple-imessage-encryption/

My current understanding of the facts:

1. Google defaults to encrypted backups of messages, as well as e2e encryption of messages.

2. Apple defaults only to e2ee of messages, leaving a massive backdoor.

3. Closing that backdoor is possible for the consumer, by enabling ADP (advanced data protection) on your device. However, this makes no difference, since 99.9% of the people you communicate will not close the backdoor. Thus, the only way to live is to assume that all the messages you send via iMessage will always be accessible to Apple, no matter what you do.

It's not like overall I think Google is better for privacy than Apple, but this choice by Apple is really at odds with their supposed emphasis on privacy.

dd8601fn• 6 months ago

ADP isn’t the default, and almost nobody who isn’t a journalist/activist/potential target turns it on, because of the serious (potentially destructive) consequences.

How does Google manage this, such every normie on earth isn’t freaking out?

miki123211• 6 months ago

Apple's other emphasis is customer experience, and there are more "I forgot my code, help me recover my stuff" people than you can imagine.

It would be bad PR for Apple if everybody constantly kept losing their messages because they had no way to get back into their account.

indemnity• 6 months ago

Enabling ADP breaks all kinds of things in Apple’s ecosystem subtly with incredibly arcane errors.

I was unable to use Apple Fitness+ on my TV due to it telling me my Watch couldn’t pair with the TV.

The problem went away when turning off ADP.

To turn off ADP required opening a support case with Apple which took three weeks to resolve, before this an attempt to turn off would just fail with no detailed error.

Other things like iCloud on the web were disabled with ADP on.

I just wanted encrypted backups, that was it.

isodev• 6 months ago

Apple's commitment to privacy

We know now that it was all marketing talk. Apple didn’t like Meta so they spun a bunch of obstacles. Apple has and would use your data for ads, models and anything that keeps the shareholders happy. And we don’t know the half of the story where as a US corp, they’re technically obliged to share data from the not-E2EE iCloud syncs of every iPhone.

astrange2• 6 months ago

Apple has and would use your data for ads, models and anything that keeps the shareholders happy.

Illegal to do this in (at least) the EU, California and China.

dangus• 6 months ago

Apple has ads. See the App Store, Apple Maps is also planning to roll out advertising.

derbOac3• 6 months ago

It's all tempered by them ultimately controlling what you can put on your phone though.

As was demonstrated in LA, it's starting to have significant civil rights consequences.

throwaway2902• 6 months ago

Security is pointless if platform allows 90% users to be social engineered into running code disabling that security

nozzlegear9• 6 months ago

What happened in LA?

ioasuncvinvaer• 6 months ago

Apple is an ad company now though

baxtr3• 6 months ago

Apple sells some ads yes. But it’s a tiny fraction of their revenue.

Would Google or Meta go bankrupt if they stopped selling ads? Yes. Apple wouldn’t.

shepherdjerred• 6 months ago

Apple's ad revenue was 1% of its total in 2024. It was estimated to be 2-3% in 2025.

https://www.apple.com/newsroom/pdfs/fy2024-q4/FY24_Q4_Consol...

https://www.macrumors.com/2025/10/30/apple-4q-2025-earnings/

eddyg2• 6 months ago

I still like to encourage people to watch all of https://www.youtube.com/watch?v=BLGFriOKz6U&t=1993s for the details (from Apple’s head of Security Engineering and Architecture) about how iCloud is protected by HSMs, rate limits, etc. but especially the timelinked section. :)

bigyabai6• 6 months ago

I still recommend Mr. Fart's Favorite Colors as a refutation, describing why all of these precautions cannot protect you in a real-world security model: https://medium.com/@blakeross/mr-fart-s-favorite-colors-3177...

  Unbreakable phones are coming. We’ll have to decide who controls the cockpit: The captain? Or the cabin?

epolanski2• 6 months ago

I claim bs at this whole apple privacy thing, nothing but propaganda.

Two years ago I was locked out of my MacBook pro.

Then I just booted in some recovery mode and just..reset the password!?

Sure macos logged me off from (most) apps and website, but every single file was there unencrypted!

I swear people that keep boasting that whole apple privacy thing have absolutely no clue what they are talking about, nothing short of tech illiterate charlatans. But God the propaganda works.

And don't start me on iMessage.

n8cpdx2• 6 months ago

You chose not to enable FileVault during setup. Probably because you were worried about being locked out and wanted an easy way to reset the password.

Would you prefer that Apple did not give you the option to disable the security feature you disabled during setup?

raw_anon_11119• 6 months ago

I still like their hardware. But let’s not pretend that there is any part of Trump’s body that he won’t kiss and sell out his customers for. If Trump asked Cook to put a backdoor in iPhones or impose tariffs on Apple, Cook would do it in a minute

nozzlegear9• 6 months ago

Cook couldn't personally put that backdoor in himself though. There would (presumably) be Apple employees who would blow the whistle if they received such a command.

JKCalhoun4• 6 months ago

My Mother Night hope is that Cook publicly shows obsequiousness only so that in private he can hold the line on backdoors, etc.

I know, I'm living in a fantasy world in my head.

jmaker10• 6 months ago

Can someone explain what the real difference is to a consumer user between an iPhone and a Pixel or a Samsung device? Across all services, push notifications, and device backups.

Both promise security, Apple promises some degree of privacy. Google stores your encryption keys, and so does Apple unless you opt in for ADP.

Is it similar to Facebook Messenger (encrypted in transit and at rest but Meta can read it) and Telegram (keys owned by Telegram unless you start a private chat)?

There are things Pixels do that iPhones don’t, e.g., you get notified when a local cell tower picks your IMEI. I mean it’s meaningless since they all do it, but you can also enable a higher level of security to avoid 2G. Not sure it’s meaningful but it’s a nice to have.

isoprophlex2• 6 months ago

Some of these companies don't make money from you, the end user, but by selling ads and data to more effectively deliver said ads.

Differences in capabilities, experience and implementation are all downstream from that. In other words, everyone pays lip service to privacy and security, but it's very difficult to believe that parties like Meta or Google are actually being honest with you. The incentives just aren't there.

With Apple, you get to fork over your wallet, but at least you seem the be primarily the user they've got to provide services to.

With Google/Meta, you're a sucker to bleed dry.

traceroute664• 6 months ago

Apple promises some degree of privacy.

Apple also makes it easier to achieve that privacy:

    - They put all the privacy controls in one place in Settings so you can audit
    - App developers are mandated to publish what they collect when publishing apps to the App Store.

bossyTeacher• 6 months ago

Can someone explain what the real difference is to a consumer user between an iPhone and a Pixel or a Samsung device? Across all services, push notifications, and device backups.

By default, Apple offers you at no charge: email aliases, private relay, Ask No Track barrier. These are just the ones I can think of right now. I am sure there are more. A big thing with Apple is not that they offer different privacy services but they make it EASY and SEAMLESS to use. No other company comes close.

fsflover3• 6 months ago

Giving all your private data to Apple is not "privacy and security", https://news.ycombinator.com/item?id=39927657

willturman• 6 months ago

You can request a downloadable a copy of any/all of the data that Apple has associated with your account at https://privacy.apple.com.

This apparently includes retrieving all photos from iCloud in chunks of specified size, which seems an infinitely better option than attempting to download them through the iCloud web interface which caps downloads to 1000 photos at a time at less than impressive download speeds.

gumby2712• 6 months ago

It sucks that Apple decided to monitize iPhone the way they have, by controlling the owners ability to install software of their choosing. Ignoring the arguments one could make about this making it "more secure" it's clearly disrespectful to the power user that doesn't want to beg Apple's permission to use their computer. I'll grant them their security claims are sound, but it's hard to take them serious regarding privacy arguments.

Our choices are either (A) an OS monitized by tracking user interaction and activity, or (B) monitized by owning the basic act of installing software on the device, both of these options suck and I struggle to give up the more open option for one that might be more secure.

microtonal• 6 months ago

Ignoring the arguments one could make about this making it "more secure" it's clearly disrespectful to the power user that doesn't want to beg Apple's permission to use their computer. I'll grant them their security claims are sound,

I wouldn't say they are sound. First, macOS provides the freedom to install your own applications (ok, they need to be signed and notarized if the quarantine attribute is set) and it's not the case that the Mac has mass malware infestations. Second, the App Store is full of scams, so App Store - safe, external - unsafe is a false dichotomy.

Apple uses these arguments, but of course the real reason is that they want to continue to keep 30% of every transaction made on an iPhone or iPad. This is why they have responded to the DMA with a lot of malicious compliance that makes it nearly impossible to run an alt-store financially.

(Despite my qualms about not being able to install apps outside the app store, I do think they are doing a lot of good work of making the platform more secure.)

dan-robertson• 6 months ago

The OP is about security and you specifically ignore security when bringing up a common flamewar topic for which much discussion has already been had on this site. Perhaps such discussion could at least be limited to articles where it is less tenuously related.

gumby2712• 6 months ago

I guess I bring it up in the sense that no matter how good their security is, it still sucks that Apple products are so hostile to their owners. It's hard to be impressed by their security work with the platform being what it is.

Security, privacy, and ownership aren't equally separated in my mind.

promiseofbeans• 6 months ago

They made C memory safe? This is a big thing to gloss over in a single paragraph. Does anyone have extra details on this?

On devices with iOS 14 and iPadOS 14 or later, Apple modified the C compiler toolchain used to build the iBoot bootloader to improve its security. The modified toolchain implements code designed to prevent memory- and type-safety issues that are typically encountered in C programs. For example, it helps prevent most vulnerabilities in the following classes:
• Buffer overflows, by ensuring that all pointers carry bounds information that’s verified when accessing memory
• Heap exploitation, by separating heap data from its metadata and accurately detecting error conditions such as double free errors
• Type confusion, by ensuring that all pointers carry runtime type information that’s verified during pointer cast operations
• Type confusion caused by use after free errors, by segregating all dynamic memory allocations by static type

vsgherzi• 6 months ago

Sort of. From my understanding they’ve been heavily using clang with fbounds checks to insert checks into functions. I think there was work done to try to insert them into existing code as well. They memory tagging in new processors help avoid overflow exploitation. Maybe someone can jump in and add more details

bri3d2• 6 months ago

Many years ago. It’s called Firebloom. I think it’s similar in theory and lineage to Fil-C.

https://saaramar.github.io/iBoot_firebloom/

1over137• 6 months ago

They made C memory safe?

They made a dialect of C with bounds safety, see:

https://clang.llvm.org/docs/BoundsSafety.html#overview

pjmlp4• 6 months ago

Yes, that is however a dialect, and one of the goals to Swift Embedded roadmap is to replace it.

ksec2• 6 months ago

So they were not joking when they say they want Swift to replace from Assembly to Javascript.

I dont think this will end well.

cyberax• 6 months ago

Somehow, they conveniently forgot to mention these "security" features:

1. Constant popups about "application requesting access" on macOS. That often happens without any user's activity.

2. If you leave the permission popup open for some time (because it's on a different screen), it auto-denies. And then you won't be able to find ANY mention of it in the UI.

3. macOS developers can't be assed to fix mis-features, like inability to bind low ports to localhost without having root access (you can open any listening port on 0.0.0.0 but you can't open 127.0.0.1:80).

LoganDark3• 6 months ago

Since 2012, Mac computers have implemented numerous technologies to protect DMA, resulting in the best and most comprehensive set of DMA protections on any PC.

Macs are PCs now? This coming directly from Apple is hilarious.

Apple Platform Security (Jan 2026) [pdf]

Related Stories