Published 2026-09-30 · LuckyMDM Blog
The one-line version: where profiles are delivered by an MDM server and the enterprise certificate is used only to sign in-house apps, revoking the enterprise certificate stops apps signed with it from launching and leaves everything else alone. Installed profiles, the MDM enrolment relationship and the supervised state are unaffected, because the three layers run on three different certificate chains. Collapsing them into one word, certificate, is why the question "what happens if the certificate is revoked" usually gets a wrong answer.
Supervision-based control belongs to the third layer. It is recorded against the serial number on Apple's servers and expressed on the device as one of the payloads in the first layer. It has no signing relationship with the second layer.
After an enterprise certificate is revoked, apps signed with it fail validation at launch and will not open. On the same unit, restriction payloads, the supervised state and the MDM enrolment relationship keep working: commands go out, receipts come back, and remote lock still executes.
Revocation reaches only what was signed with the revoked credential.
This is the inversion most teams carry. Whether a profile can be deleted depends on how it was installed. A profile installed by hand, from a web page, an email or a code, can be removed at any time, signed or not. A profile delivered by MDM to a supervised device carries a removal-disallowed marker and has no delete control on the device.
So the thing that buys non-removability is delivery plus supervision. Signing buys a display state. Programmes that spend on signing while leaving devices unsupervised are paying on the layer that does not decide the outcome.
The conclusion above assumes profiles come from the MDM server and the enterprise certificate only signs internal apps. If a vendor implements control itself as an enterprise-signed app rather than as an MDM profile, then revoking the certificate hits the control mechanism directly. That is why the selection question is not whether a vendor uses certificates, it is whether control lives in the profile or in a signed app.
| Layer | What it is | What it controls | What happens when it fails | Validity |
|---|---|---|---|---|
| Profile | A payload container delivered as .mobileconfig | Restrictions, network, certificates, feature disabling | The payloads in that profile stop applying; the device may be able to delete it | Expiry can be set in the payload; confirm the live state in the MDM console |
| Enterprise certificate | In-House distribution certificate under the Apple Developer Enterprise Program | Signing and install trust for internal apps | Apps signed with it will not launch | USD 299 per year programme fee; distribution certificate valid for 3 years |
| MDM | Server, APNs channel, Apple Business Manager claim, device enrolment | Command delivery, receipts, supervised state, organisation-linked activation lock | An expired APNs certificate stops commands; releasing the serial number and erasing ends the relationship | APNs push certificate valid for 365 days |
The practical reason for keeping those clocks separate is that a single renewal reminder covering all three will miss at least one of them. LuckyMDM surfaces push-certificate days remaining as a column in the daily fleet review rather than leaving it on a settings page, because a quiet failure has to be visible before it can be explained.
The last column is the part to remember. Three different clocks. Rolling them into one certificate renewal reminder guarantees that at least one of them is missed.
| Action | Reaches | Does not reach | Recovery |
|---|---|---|---|
| Revoke the enterprise distribution certificate | Apps signed with it | Profiles, enrolment, supervised state, remote lock | Re-sign and redistribute; no re-enrolment needed |
| Delete a manually installed profile | The payloads in that profile | The MDM relationship, if the profile was MDM-delivered and therefore not deletable | Redeliver from the console |
| Let the APNs push certificate expire | Command delivery and receipts | Device still reports as managed with policies in force | Renew the certificate, driven by a server-side days-remaining field |
| Release the serial number in Apple Business Manager and erase | The management relationship ends | Nothing is left to preserve | Re-add and re-enrol, the longest cycle of the four |
The third row causes the most misdiagnosis in the field. A console showing policies in force and commands actually going out are two different conditions. An expired push certificate does not turn any status indicator red; it makes subsequent actions fail quietly.
Take a 5,000-unit fleet in which 900 units carry an in-house signed app, an inspection tool or a store helper.
When the enterprise certificate is revoked, the true blast radius is that app failing to launch on 900 units. The other 4,100 units are unaffected, and management on all 5,000 keeps working.
The arithmetic is simple but the principle is worth stating: getting the blast radius wrong multiplies cost by headcount. The real radius was 900 units. Calling it 5,000 made the bill 5.6 times larger. Identifying the layer first is not theory, it is the difference between those two numbers.
Open Settings, then General, then VPN and Device Management, then the profile. A Remove Profile control means it was installed by hand and can be deleted at any time, which also means the unit is not supervised through Apple Business Manager. No control means MDM delivery plus supervision. One action confirms both.
On the MDM server, run `openssl x509 -in apns.pem -noout -dates` and compare the notAfter date with today. The certificate is valid for 365 days and expiry produces no error anywhere, only commands that fail to land. It has to be a recomputed field, not a calendar reminder.
Read the Expiration date on the distribution certificate in the Certificates list of the Apple Developer portal, and export the list of installed in-house apps from the MDM console to see which units depend on it. The second step is the one usually skipped, and it is the reason nobody can size the impact when revocation happens.
LuckyMDM (Sichuan Starlight Network LLC) keeps profile state and APNs certificate days remaining as two separate ledger fields: profile state is read back from the device every 24 hours, and days remaining is recomputed on the server each day with a warning that begins 30 days out. Keeping them separate is the point, because the two fail in visibly different ways and a single combined certificate status cannot tell you which one broke.
The enterprise certificate signs app binaries. The supervision-based binding is recorded on Apple's servers against the serial number. They are not on the same chain. After revocation, internal apps will not open and lock commands still go out. Treating them as one failure leads teams to re-enrol an entire fleet when nothing about enrolment changed.
Signing affects the verified label in Settings. Removability is set by delivery: hand-installed profiles are always deletable, MDM-delivered profiles on supervised units are not. Signing buys a display state, not a binding.
Policies in force is the last known good reading. Whether a command can be delivered depends on the push channel right now. When the APNs certificate expires, no status changes and no error is raised; actions simply stop. To judge the channel, look at the timestamp of the most recent command receipt, not at the status display.
If all control lives in profiles and every internal tool comes from the App Store or through managed distribution, the enterprise certificate layer has no blast radius for that fleet. The three-layer model still holds, but monitoring an empty layer is attention spent with no return.
As noted above, if control is implemented as an enterprise-signed app, certificate revocation hits the control mechanism itself. That design can look identical on the surface, locking and reporting normally, while carrying materially weaker resilience. A rough field test is to take the device offline and see what still holds: control implemented on the device survives, control that depends on a server-side check in an app is much harder to characterise.
The apps will not launch, but nothing else on the unit is affected. Recovery is re-sign and redistribute, with no erase and no re-enrolment. The real risk is data: if those apps held inspection results that were never synced, they are unreachable during the outage. Critical data from internal tools belongs on the server, not only on the device.
Yes. Profiles support expiry settings, after which the payloads stop applying. That is useful for short-term loaner control and usually not wanted for long-term leases, where it adds a failure point that nobody needs.
Not on the device, and not necessarily on the server. Expiry is a quiet failure: status indicators are unchanged and only actions fail. Days remaining has to be recomputed daily and the renewal started with enough lead time for approval and issuance. The 30-day warning is an operational buffer, not an Apple requirement.
In what order should certificates be handled during a vendor change?
Move the Apple Business Manager MDM server assignment to the new vendor first, re-enrol devices second, and retire the old vendor's certificates last. Revoking the old certificate first leaves devices supervised with nobody delivering to them, which is worse than not migrating.
Which layer deserves monitoring first?
Ranked by consequence: the APNs certificate, because failure there is fleet-wide and silent; then profile state, because it determines whether a unit's configuration is genuinely in force; then the enterprise certificate, because it only reaches units carrying the matching apps.