← Field Notes

Endpoint posture · Field note

Your phone fleet is the one you cannot investigate at a distance

R Rob Flanagan · Sep 2026 · 13 min read

The same architecture that makes an iPhone hard to compromise makes it hard to investigate. If your second factor lives on that phone, that is the platform holding the keys to everything else.

I have managed 540+ iPhones and iPads next to 569 Macs.

Both arrive defended. Secure Boot, a signed system volume, System Integrity Protection, Gatekeeper and XProtect are on a Mac before anybody configures anything, and SIP is documented as on by default and applied "to every process running on the system, regardless of whether that process is running sandboxed or with administrative privileges." What differs is how much of the posture sits above that baseline for me to author, and how much I can see afterward.

That gets read as "phones are safer." I do not think it holds, and the reason it does not hold is the part of this comparison that almost never gets made.

Compare them the same way: out of the box, before management

Most iOS-versus-macOS arguments compare a managed iPhone to an unmanaged Mac. That is not a comparison, it is a configuration difference. So compare them at the same point instead, which is the moment before either one is enrolled in anything.

iOS and iPadOS put the model in the architecture

All third-party apps are sandboxed. Apple states this directly in the Platform Security guide's description of runtime process security.

All executable code must be signed with an Apple-issued certificate. Again, Apple's own wording, from the app code signing section.

There are no kernel extensions. Drivers built with DriverKit "run in user space, rather than as kernel extensions," and third-party drivers do exist, but it is worth reading the platform badges and the prose separately, because they do not say the same thing. The badges list DriverKit 19.0, iOS 16.0, iPadOS 16.0, Mac Catalyst 16.0 and macOS 10.15. Apple's own description of the framework is narrower: DriverKit "defines the fundamental behaviors for device drivers in macOS and iPadOS", and the base framework is available "in macOS for Apple silicon and Intel-based Mac computers, and in iPadOS for devices with an M-series chip". So the third-party driver path Apple actually describes is a Mac and M-series iPad one, and it does not describe an iPhone. What Apple documents no path to anywhere is third-party code in the kernel; the Kernel framework's platform list names macOS only.

Setting a passcode turns on Data Protection. There are no administrator and standard account tiers, and apps run as one nonprivileged user. Shared iPad is the exception worth naming: it does provision separate user IDs.

macOS leaves most of that reachable

The sandbox is mandated for one distribution channel only: "To distribute a macOS app through the Mac App Store, you must enable the App Sandbox capability." Everything outside that channel may skip it.

By default, software is checked for known malicious content the first time it opens, however it arrived. Both of Apple's qualifiers matter: "by default," because the same page says Gatekeeper "can also be completely turned off, if necessary," and "for known malicious content," because a check is not a review. A user can allow something that check blocked, unless device management stops them. That phrasing is Apple's, from the Gatekeeper and runtime protection section: users can override Gatekeeper policies unless restricted by a device management service.

Apple silicon Macs encrypt the volume either way. What FileVault changes is what protects the key. With FileVault off, Apple says the volume encryption key is protected only by the hardware UID in the Secure Enclave. With it on, that key is bound to a password as well. Apple documents the default on its Data Protection overview page rather than on either FileVault page: "On a Mac with macOS 26.4 or later, FileVault is turned on by default," followed immediately by "Users can opt out if desired." That is recent enough that a fleet in service today will have machines on both sides of it, and an opt-out is not a guarantee. Getting the recovery key somewhere your organization can retrieve it is a separate job that no default does for you.

Accounts split into administrator and standard, so somebody decides who gets which.

The five-row version

Every row is about third-party software. Both platforms ship Secure Boot, a signed system volume and code-signing enforcement that no row here covers, so this is not a scoreboard and reading it as one gets the wrong answer.

Third-party software, out of the box	iOS	macOS
Apps sandboxed	enforced	App Store apps only
Code must be Apple-signed	enforced	checked by default; user can override unless device management stops them
Kernel extensions	not offered	only after downgrading to Reduced Security, approving, and restarting
Process and file event API for security tools	Apple documents none	Endpoint Security, entitlement required
Administrator and standard account tiers	not offered (except Shared iPad)	you decide who gets which

The kernel-extension row deserves its detail rather than a shrug. Apple's requirement on Apple silicon is to hold the power button into One True Recovery, enter an administrator password, downgrade to Reduced Security, tick the box, and restart. That is a long way from "you configure it."

Read that table as a description of where the work sits, not as a scoreboard. Everything in the macOS column is a thing you can get right. Everything in the iOS column is a thing you cannot get wrong, and also cannot adjust.

That openness is why a Mac is worth handing to an engineer. It is the same openness the rest of this post is about.

The part I almost never see argued

The same architecture that hardens iOS is why I cannot see into it.

macOS gives security tools the Endpoint Security framework. Apple's own description is worth quoting exactly, because the exact wording is the whole point: "Your client registers with Endpoint Security to authorize pending events, or receive notifications of events that already occurred. These events include process executions, mounting file systems, forking processes, and raising signals." Apple's availability metadata lists macOS and Mac Catalyst; iOS and iPadOS are absent. Access is gated too, behind an entitlement Apple says "you must request."

Note what that is and is not. It is a live subscription. A client has to be installed, entitled, running, and subscribed at the moment something happens, and whatever you can ask later is whatever that product chose to retain. Apple documents no built-in, queryable execution history on a Mac. The framework is the plumbing for one; it is not one.

Apple documents no iOS equivalent, and no device management catalog item that returns an execution history. Look through Apple's commands and queries and you can retrieve what is installed. Apple documents nothing there that returns what ran. The nearest neighbors are all current-state inventories: Installed Application List, Managed Application List, Active NSExtensions, Security Info, Device Information.

I can tell you what is installed. I cannot tell you what ran.

Being precise about this, because the strong version is wrong

It would be easy to write that there is no record on the phone at all. That is not true, and it is worth saying why.

iOS runs a unified log, and Apple publishes collection instructions for both sysdiagnose and Console Logs on iOS and iPadOS through its Feedback Assistant profiles and logs page. A record exists. Under some circumstances, with the device in hand and a person willing to run through a capture procedure, you can get at some of it.

What Apple does not document is administrator reach into it. Apple's availability metadata for OSLogStore.Scope.system lists macOS 12.0 and later only, while the enclosing OSLogStore.Scope enum lists iOS, iPadOS and four other platforms. Apple documents no device management command that returns the log, and no third-party framework that subscribes to it the way Endpoint Security subscribes on macOS. A sysdiagnose is a file a person captures on a device they are holding, at a moment they chose, and mails to someone. It is not a console, it is not queryable, and it is not something you run across a fleet on a Tuesday afternoon because a detection fired.

So the accurate claim is about reach rather than existence, and the accurate claim is also the stronger one.

One more piece of precision, in the same spirit, and it cuts against the Mac side of my own argument. Ask me what a Mac in that fleet ran last Tuesday and there is an answer only if an Endpoint Security client was subscribed at the time and its retention still covers Tuesday. Apple documents no built-in record macOS holds on its own. The Mac advantage is not that the machine remembers; it is that the machine will tell a tool you bought, deployed and configured. Ask the same about one of the phones and Apple documents nothing there for such a tool to subscribe to.

There is also a beta command a skeptic will raise, and they should: TriggerEnhancedLogCollection, documented for iOS, iPadOS, Mac Catalyst, macOS and tvOS 27.0 and marked beta. Its paired status items are a status, a token and a timestamp. Apple does not document it as returning a list of processes that ran.

So the trade runs both ways

iOS hands me a posture I did not have to build, and gives third-party security tools no documented process-level view of it. macOS gives me that view, and makes me build the posture. "Keeps the evidence" would be too strong in the iOS column: sysdiagnose and Console log collection exist, and the narrow, defensible claim is about routine third-party process telemetry rather than about evidence in general.

Neither of those is a bad deal on its own. The problem is what happens when you put them next to each other in the same organization and never say out loud which one you are relying on for what.

And if your second factor and passkeys live on those phones, the platform with the least third-party process visibility is holding the keys to everything else. That is a claim about one dimension, not about every security domain: identity provider, relying party, MDM, sign-in and recovery logs can still answer a great deal about a credential. Nobody signs off on that trade, because it never arrives as a decision. It arrives as a convenience: passkeys are better than passwords, the phone is the thing everyone already has, and the enrollment flow is three taps. Every one of those statements is true. The consequence is still that your most sensitive authenticator sits on the endpoint with the least investigative surface.

I am not arguing you should move your second factor off the phone. I am arguing you should know that is the trade you made, so that when someone asks whether a given phone was compromised before a login, you already know what your answer is going to be.

The objection: the hardware gap is closing

The usual response to all of this is that the hardware difference is the real story, and that it is narrowing.

It is narrowing. Apple's Platform Security guide states it in one sentence: Memory Integrity Enforcement is "a comprehensive memory safety defense for Apple platforms available on A19 and M5 processors or later." The same page's SoC feature table marks that row supported only in its final column, headed A19 / M5; the six earlier columns are marked not supported. Apple Security Research has written the protection up at length.

That is a statement about silicon. Whether an operating system turns a protection on for third-party apps by default is a different question, and it is this post's question. A Mac and an iPhone can share a memory-safety feature and still differ completely on whether the sandbox is mandatory, whether a user can override a code-signing check, and whether an administrator account exists to be handed out. The architecture argument and the silicon argument are not the same argument.

What I would actually do about it

Two things, and the first is the one this post actually argued for.

Decide what your Mac visibility is, before you need it. The Tuesday answer is a product you bought and a retention window you set, not a property of the platform. If nobody can say which Endpoint Security client is subscribed on your fleet and how far back it holds events, you do not have the advantage this post credits macOS with; you have the option to buy it. And accept that the iOS side of that question currently has no good answer, so plan the phone half around identity and MDM signals rather than around endpoint telemetry Apple documents no way to collect.

Then handle administrator rights. This is one high-impact control, not the whole posture, and it is worth being exact about its blast radius. CrashStealer never needed it, which is the honest limit on what this control buys you. It does not touch Secure Boot, the signed system volume, System Integrity Protection, FileVault recovery-key escrow, or the Endpoint Security entitlement; Apple documents SIP as applying to every process "regardless of whether that process is running sandboxed or with administrative privileges." What it changes is narrower and concrete: who can approve a system extension, make elevation-required changes, and install software system-wide. A standard account does not stop software from running out of user-writable locations or stop a user from overriding Gatekeeper. Apple's wording draws the latter line exactly: a user can override the policy unless device management stops them.

So decide who holds them deliberately. Not as a ticket-deflection default, not as a hiring-class default, and not as something inherited from whoever set the fleet up before you. Write down the rule, write down the exceptions, and be able to say how many accounts are on each side of it.

The phone's posture is inherited. The Mac's is authored, and it stays true only as long as you keep authoring it.

Four things I scoped deliberately

"Signed" is not "reviewed." A developer can build and run their own code with Developer Mode, which Apple says reduces the security of the device, and EU alternative marketplaces have existed since iOS 17.4. The signing requirement holds in all of those cases. App Store review is a separate thing and I am not claiming it.

The Gatekeeper override wording is Apple's. Apple's guide adds that Gatekeeper "can also be completely turned off, if necessary."

FileVault defaulting on is recent, and the default is not the control. Apple's Data Protection overview says that on macOS 26.4 or later it is on by default and users can opt out. Worth knowing that neither FileVault page carries that sentence, which is how a careful reader can check the guide and conclude the default is undocumented; it is on a third page. A recovery key exists once FileVault is on. Escrowing it somewhere your organization can retrieve it is the separate part, and it is the part that gets missed.

iPads are in the count. The architecture claims apply to iPadOS, with one exception noted above: DriverKit is the single place where Apple's prose separates them, describing a driver path for M-series iPads that it does not describe for iPhone. A shared iPad in a store also has a physical-access profile that a phone in a pocket does not. Different problem, different post.

Credit to the MacAdmins Podcast crew for the iOS and macOS security conversations that shaped this one.

Sources

Apple primary sources. The original source list was fetched on 2026-09-06; the Developer Mode and alternative-marketplace sources were added and checked on 2026-09-08. Two pages Apple has since renamed are cited at their current addresses. Claim-level verification for this post is recorded in a per-claim citation bank dated 2026-09-05:

← Back to Field Notes