The APNs renewal trap: renew, never recreate — and the Apple ID question settled

Your Apple MDM push certificate is expiring, the Apple ID that created it belonged to an ex-employee or an outside consultancy, and the first two pages of Google give you flatly contradictory answers to a decision that can orphan every managed Apple device you have. Here is what actually preserves device trust, what the Apple ID really controls, and the safe path through.

The problem

Every Intune tenant that manages iOS, iPadOS or macOS devices depends on a single Apple MDM push certificate (the APNs certificate). It is valid for 365 days, and when it comes up for renewal — or has already lapsed — the admin doing the job is frequently not the person who created it. The original Apple ID often turns out to belong to someone who left the company, or to an MSP the business no longer works with.

Search for guidance under that pressure and you find two authoritative-sounding statements that appear to contradict each other:

“Once a certificate has been requested using an Apple ID, you cannot use a different Apple ID to renew that same cert.” If you create a new certificate instead of renewing, you are forced “to unenroll and re-enroll all existing, Intune-managed iOS devices”. — Microsoft Intune support team, “Intune and the APNs certificate” FAQ (Microsoft Tech Community)

Microsoft’s official documentation on Microsoft Learn says the same thing in fewer words: “Renew the MDM push certificate with the same Apple account you used to create it.”

“Changing Apple ID has no impact.” — c7solutions blog (a widely-read SME post on renewing Apple tokens in Intune)

Both cannot be operational advice for the same decision — and the cost of choosing wrongly is severe. A new certificate silently severs Intune’s ability to reach every enrolled Apple device. There is no undo: recovery means unenrolling and re-enrolling the entire Apple fleet, device by device, usually with end-user involvement.

Who hits this: any Intune admin approaching (or past) the annual APNs renewal, and especially anyone who has just discovered the certificate’s Apple ID is not under company control.

Why it happens

The confusion exists because two different bindings are being conflated. Separate them and the contradiction dissolves.

1. Device trust is anchored to the certificate lineage — the push topic

When the APNs certificate is first created, Apple assigns it a topic — a unique identifier of the form com.apple.mgmt.External.<GUID>, stored in the certificate’s subject (UID field). Every Apple device you enrol bakes that topic into its management profile: it will accept MDM push notifications for that topic and no other.

• Renewing the certificate keeps the same topic. The serial number and expiry change; the lineage — and therefore device trust — is preserved. Devices carry on as if nothing happened.
• Creating a new certificate mints a new topic. Intune’s pushes now go out under an identifier your existing devices were never enrolled against. Every device is orphaned, and the only remedy is full re-enrolment. This is the one-way door.

2. The Apple ID is an access control, not a trust anchor

The Apple Push Certificates Portal (identity.apple.com) lists a certificate only under the Apple ID that created it. That is where Microsoft’s warning bites: sign in with a different Apple ID and the certificate you need to renew simply is not there — so you cannot renew it, and the tempting button in front of you creates a new certificate instead. The devices themselves do not know or care which Apple ID performed the renewal; they only care that the topic is unchanged.

That is the kernel of truth in the “changing Apple ID has no impact” claim: in genuine recovery cases, Apple support can sometimes re-associate an existing certificate with a different Apple ID, and once that is done the new ID can renew the same certificate — same topic, devices unaffected. But that is an Apple-mediated exception, not something you can do yourself in the portal.

The definitive rule: what preserves your fleet is renewing the same certificate lineage (same topic). The Apple ID question is about whether you can get to that certificate to renew it — and by default only the original Apple ID can.

The fix

Work through this in order — it is designed so that the irreversible option is never taken by accident.

Step 1 — Establish exactly what you have

1. In the Intune admin centre, go to Devices > Device onboarding > Enrollment, open the Apple tab and select Apple MDM Push Certificate. The blade shows the Apple ID that created the certificate, its status and its expiry date — record both. (It does not show the certificate’s serial number.)
2. Sign in to the Apple Push Certificates Portal at identity.apple.com and find the matching certificate — match the entry by expiry date and Apple ID against what Intune shows. Click the info icon on that entry and note the serial number and the UID: the UID is the push topic, the com.apple.mgmt.External.<GUID> value that device trust is anchored to.
3. Alternatively — the method Microsoft Learn documents — read the topic straight from any enrolled device: Settings > General > Device Management > Management Profile > Topic. Either way, the topic is your ground truth for verifying the renewal later.

Step 2 — If you control that Apple ID: renew, never create

1. In Intune, on the same Apple MDM Push Certificate blade (Devices > Device onboarding > Enrollment > Apple), start the renewal and download the certificate signing request (CSR) that Microsoft signs for you.
2. Sign in to the Apple Push Certificates Portal at identity.apple.com with the same Apple ID Intune recorded.
3. Find the existing certificate — the entry you matched by expiry date and Apple ID in Step 1 (double-check the serial number you noted from its info icon). Click Renew on that entry. Do not click the button that creates a new certificate, however prominent it is.
4. Upload the CSR, download the renewed .pem, and upload it back into Intune, entering the same Apple ID when prompted.

Step 3 — Verify the lineage survived

• The expiry in Intune should now show roughly a year out.
• The topic (subject UID) must be unchanged. The serial number will be new — that is normal for a renewal — but a changed topic means a new certificate was created and you should stop and reassess before devices start missing check-ins.
• Sync a test device and confirm it still responds to an Intune action.

Note: even if the certificate has already expired, do not create a new one. Microsoft documents a 30-day grace period after expiry in which the certificate can still be renewed — so renew immediately, within that window. The Apple portal still lists the expired certificate; renewing the same entry and uploading it to Intune restores management of existing devices without re-enrolment.

Step 4 — If the Apple ID is lost or belongs to someone else

1. Try account recovery first. If the Apple ID was created on a company mailbox (including an ex-employee’s mailbox you still control), a password reset through that mailbox is the cleanest route back in.
2. Contact Apple support for the Apple Push Certificates Portal. In recovery cases Apple can sometimes re-associate the existing certificate with a different Apple ID — preserving the topic and your fleet. This is discretionary and takes time, so start early.
3. Only as a last resort, and as a planned decision rather than an accident: create a new certificate and schedule a controlled re-enrolment of the Apple estate. Accept that this is a migration project, not a renewal.

Step 5 — Make sure this never recurs

• Create a shared service Apple ID — for example apple@yourdomain.com on a monitored shared mailbox — and, if you are stuck using a personal one today, plan the Apple-mediated re-association at a calm moment rather than at expiry week.
• Keep the two-factor phone number and recovery details under company control, not on an individual’s handset.
• Record the Apple ID, mailbox, certificate serial, topic and expiry date in your break-glass or credentials register.
• Set a calendar reminder comfortably ahead of the 365-day expiry, assigned to a team, not a person.
• If an external party ever created the certificate on your behalf, get the account details documented and transferred now — this is a conversation you do not want to be having the week the certificate lapses.

How Decolla handles it

Straight answer first: Decolla provisions Windows devices over your own Intune and Autopilot tenant. It does not touch, renew or manage your Apple MDM push certificate, so it does not solve APNs renewal for you — the steps above are the fix.

What Decolla is built to do is eliminate this class of failure on the Windows side. The APNs trap is really two failures compounding: an undocumented credential owned by the wrong person, and an irreversible action taken under pressure because it looked like the routine one. Decolla’s answer to both is its written, itemised build plan: before anything runs in your tenant, every item is set out with its delivery method and its reversibility class — automatic, reversible, or explicitly flagged as irreversible — and the plan is approved before a single change is made. Tenant-level prerequisites, including who owns which identity or token, are captured as named, documented prerequisites in that plan, so one-way doors are identified and assigned an owner on day one instead of being discovered at expiry. And where Decolla does make changes, they are its own changes, rolled back item by item on request.

Decolla is currently pre-launch; if that plan-first, no-silent-one-way-doors approach to Windows provisioning is what your tenant is missing, the waitlist is open at decolla.app.

Sources

• Microsoft Learn — Get an Apple MDM push certificate for Intune
• Microsoft Tech Community — Intune and the APNs certificate: FAQ and common issues
• System Center Dudes — Renew Apple MDM push certificate in Endpoint Manager
• c7solutions — Renewing Apple tokens in Intune