Why Unsupported iPhones Belong on a Retirement Schedule

Unsupported iPhones belong on a retirement schedule because a phone that can no longer run a current iOS release keeps collecting unpatched browser and kernel bugs while it still holds email, SSO sessions and saved passwords. Attackers know this. In late 2026, an APT29-linked campaign reused years-old n-day exploits against iPhones on iOS 16. Setting a replacement date in policy, with budget behind it, is cheaper than cleaning up after one stolen session.

Why do attackers target unsupported iPhones?

Attackers target unsupported iPhones because exploits for them are cheap, already public or resold, and still work. A patch only protects devices that can install it.

Sekoia's November 2026 Poisoned Source report shows the economics. The operators used three exploit chains, every one of them built from vulnerabilities fixed before the campaign started. Sekoia believes APT29 obtained them from a third party rather than developing them. The chains were served from compromised and lookalike websites, and through a hijacked analytics tracker loaded by thousands of sites, to any visitor whose phone matched an old version. Read our coverage of CVE-2024-27834 and the Poisoned Source campaign for the specifics.

Why the last available update is not enough

A device at the last iOS build its hardware supports is not the same as a patched device. Apple backports some fixes to older branches, but not all of them, and the gap widens over time.

The Sekoia case shows this directly. Apple fixed CVE-2024-27834, the Pointer Authentication bypass in the iOS 16 chain, in iOS 16.7.8. But the CVE record for CVE-2025-43529, the WebKit bug that starts the same chain, lists fixes only in iOS 18.7.3 and iOS 26.2. A phone stuck on iOS 16 can show "up to date" in Settings and still lack a fix for a bug attackers used against it.

When a device reaches that state, treat it as unsupported regardless of what the Settings screen says. For why one missing fix can matter so much, see what Pointer Authentication is and what a PAC bypass does.

What is the real risk of keeping old phones?

The real risk is identity, not the phone. The device is the way in; the payload is the access stored on it.

What the Poisoned Source chains took:

• iOS 16 chain: browser cookies, which can let an attacker reuse logged-in sessions, including webmail.
• iOS 18.5 chain: SMS and iMessage, Mail indexes, WhatsApp and Telegram databases, Keychain passwords and tokens, account credentials, Wi-Fi keys, contacts, call history, photos and location data.
• Android Chrome chain: Chrome cookies, saved logins, history and Wi-Fi passwords.

None of these chains needed a click, and none set up persistence. The phone may look clean after a reboot while the stolen sessions keep working. A patched replacement does not undo that, so retirement has to come before the incident, not after.

How should IT plan device retirement?

Plan device retirement as a dated policy with a budget line, not as a reaction to a breach. Tie the retirement trigger to vendor support, then work backwards to purchasing.

A workable policy has four parts.

Define the trigger

Retire a device when it cannot run the current major iOS release, or when it misses a security fix your team has classed as mandatory. Write both conditions down. "When it gets slow" is not a trigger.

Set the grace period

Give owners a fixed window after the trigger, such as 60 or 90 days, and cut it short when a KEV entry or vendor advisory says an unfixed bug on that branch is being exploited. During the grace period, limit the device to low-risk access.

Fund it in advance

Unsupported hardware arrives in waves after each major iOS release. Forecast the next wave from your MDM inventory (model and OS) and put the replacement cost in the coming budget cycle. Leadership approves planned spend far more easily than an emergency purchase.

Enforce it technically

Policy without enforcement drifts. Use MDM compliance rules and Conditional Access so that devices past their grace period lose access to email, files and SSO automatically. The mechanics are in how to enforce a minimum iOS version with MDM.

What about personal devices (BYOD)?

Personal devices need the same version floor, enforced through access rather than ownership. You cannot replace an employee's phone, but you can refuse it access.

Apply the same compliance rules to enrolled personal devices, or to app-level controls where you only manage the work apps. Tell staff the floor in advance and explain that an unsupported phone will lose work email on a known date. Offer a company device or browser-only access on a managed laptop for people who cannot upgrade.

Questions to bring to leadership

• How many devices in our inventory cannot run the current major iOS release?
• Which of those can reach email, file storage or SSO today?
• What is the replacement cost, and which budget cycle covers it?
• Who signs off on exceptions, and when do they expire?

The point for leadership: old exploits are cheap and widely shared, and the data they steal from an unsupported phone belongs to the organization. A retirement date is the control that makes those exploits useless.