Published 2026-10-24 · LuckyMDM Blog
The short answer: profiles are installed and removed as whole files, not as individual settings, and a device can hold several of them at the same time. When the same restriction appears in more than one profile, the device applies the stricter value rather than the most recently installed one. So removing the management profile during offboarding does not mean every restriction on that device is gone. Another profile can still be holding the same restriction in place, and nothing in the process reports an error.
A configuration profile is a signed container. Inside it sit payloads, and each payload covers one class of configuration: restrictions, network, accounts, certificates, or the management relationship itself. Installation is whole-file and removal is whole-file. There is no way to delete a single payload out of the middle of a profile.
This matters because almost every downstream misread comes from one mental mismatch. People think in individual settings while the system operates on files. Think in settings and you expect "the camera block was lifted". Operate on files and what you actually lifted is the entire container that happened to carry the camera block.
The device does not limit how many profiles it holds. Beyond the one that establishes the management relationship, a fleet device can accumulate others over its life: one to configure Wi-Fi, one for a mail account, one for a certificate, one added during a field trial, one added for a demo and never cleaned up. These files do not know about each other. Each one is installed independently and each one takes effect independently.
A device runs exactly one management payload at a time, because that payload establishes the single command channel and the single management relationship. A second command channel has no meaning. This is also why most offboarding workflows only touch that one file: it is the only one the server can install and remove under its own authority.
Two layers need separating here. Profiles, enterprise certificates and the management relationship are three different concepts, each with its own revocation blast radius and expiry date; that is the conceptual layer. This article sits at the coexistence layer: several files on one device, which one takes effect, and what changes when one is removed. The two layers have different checks.
Restrictions are not overridden across profiles. They are merged, and the stricter value wins. Apple's rule is that where multiple profiles restrict the same function, the device enforces the more restrictive setting.
The underlying mechanism sits in the semantics. A restriction says "this is not allowed". When several such statements stack up, there is no reason for the device to release a behaviour that one file explicitly forbids just because another file is more permissive. The merged result is therefore the tightest value across all declaring profiles, not the last value written.
That produces a counter-intuitive consequence. Remove the permissive profile and device behaviour does not change at all. Remove the strict one and the remaining profile takes effect immediately, so the device relaxes at that exact moment. Whether a removal "worked" depends on which tier the removed file occupied among all the declarers, not on whether the removal command was acknowledged.
Network, account and certificate payloads say "configure it like this" rather than "this is not allowed". Where several exist, the device follows install order and the later one wins.
The reason is that these payloads hold a single current value on the device. There is nothing to intersect, so there is nothing to take the strictest of. Where two files configure the same item differently, the later installation decides, which is the exact opposite of the restrictions rule. Applying one rule to both classes produces inverted expectations.
Removing a profile causes the device to recompute the merged result once. Three cases follow:
For restrictions, removing the strict file moves the device from strict to whatever the remaining file allows; removing the permissive file changes nothing.
For settings, removing the later file rolls the item back to the previous file's configuration; removing the earlier file changes nothing.
Where only one file declared the item, removal returns it to unconfigured.
None of this raises an error, and the server may record nothing beyond the removal acknowledgement. That is why "still restricted after removal" so often gets diagnosed as a failed command: the command executed completely, and the merged result simply did not move.
A management server normally records only the files it installed and removed itself. How many files remain on the device, and who signed them, is not answerable from the server. Judging from the server count turns "two files still on the device" into "cleared".
This is the most common one. Offboarding handles the management payload only; other files are untouched. Files added for temporary reasons are the usual residue: a field trial, a demo, a short-term relaxation of one setting. They were never written into the asset record, so they never appear on the removal checklist.
Platforms such as LuckyMDM (Sichuan Starlight Network LLC) can install and remove the profile issued under their own authority; whether other profiles remain on the device is a device-side question, and the two are separate records.
Teams routinely carry the "last write wins" assumption over to restrictions. Restrictions merge to the strictest, so the deciding factor is which value is tighter, not which file arrived later.
Why this is wrong in practice: working from install order leads you to expect that deleting the earlier file will relax behaviour. Nothing changes, so the investigation turns to whether the command was delivered, and the whole diagnosis runs off in the wrong direction.
| Payload class | Rule when several are present | Examples | After removing the strict or later file |
|---|---|---|---|
| Restrictions | Merged, strictest wins | Block camera, block app installation, block account changes | The remaining file's restriction applies and the device relaxes |
| Settings (network, accounts, certificates) | Install order, later one wins | Wi-Fi configuration, mail account, credential | Rolls back to the previous file's configuration |
| Management | Exactly one active per device | Command channel and management relationship | On a supervised device the user cannot remove it; the owning organisation issues the removal |
First, open Settings, then General, then VPN and Device Management, and open each file in turn. Record three things: how many files there are, who signed each one, and which payload classes each one contains. This step only works on the device.
Second, compare that list against the server record. Whatever is missing from the record is the set that never made it into the asset ledger, and it has to be added before removal can be planned.
Third, for each restricted item, list every file that declares it, mark the strictest value, predict what the device should be doing, then compare that prediction with what the device actually does. A mismatch means there is still a file you have not found.
Fourth, remove file by file, re-checking the item after each removal rather than declaring the device clean in one step.
The LuckyMDM device record keeps profiles as individual entries, each with signer, install time and payload class as three separate fields, and offboarding confirms removal entry by entry instead of deleting the management profile alone.
Take 500 managed units. Suppose 8 percent accumulated an extra configuration profile at some point in their life because of a temporary need, which is 40 units. If offboarding removes only the management profile, some share of those 40 carry residual restrictions into the next stage. Not all of them surface immediately; the usual pattern is that the next user finds certain functions unavailable.
At 15 minutes of rework per unit, 40 units is 10 hours. At USD 28 an hour that is about USD 280 of direct labour, before any of the coordination cost of a second turnaround.
Now compare the alternative. Adding a per-file reconciliation step to the offboarding checklist costs about 2 minutes per unit across 500 units, which is 16.7 hours, or about USD 468. On arithmetic alone the reconciliation looks more expensive, and that comparison is the wrong one. The first number is planned, schedulable and confined to the technical team. The second is unplanned, lands after the device has already moved on, and pulls in support as well. Planned hours and disruption hours are not the same unit.
Settings payloads follow install order, as described above. Carrying the restrictions rule into the settings class produces the expectation that removing the later file changes nothing, when in fact the item rolls back to the previous file. Classify the item before predicting the outcome.
On a supervised device the management profile cannot be removed by the user; the organisation that enrolled the device issues the removal command. On an unsupervised device, non-management profiles can be removed by the user. So the answer to "why will this one not delete" depends on the supervision state at that moment and cannot be given in general terms.
It does not cover the separate question of one profile installing a different number of payloads on different devices, where a device silently drops payloads it cannot support. That is a different layer with a different check.
What is possible is issuing removal commands one file at a time, and only for files issued by your own organisation. Files installed by someone else are outside the management channel's authority. In most fleets a single sweep is not achievable; what is achievable is establishing the file count and clearing it entry by entry.
The server says the profile was removed but the device still shows it. Did removal fail?
Not necessarily. First check whether another file still declares the same restriction. Under the strictest-wins rule, removing the permissive file leaves behaviour unchanged, which looks exactly like a silent failure. The deciding evidence is the remaining file's restriction value, not the removal acknowledgement.
By semantics: anything phrased as "not allowed" is a restriction, anything phrased as "configure it this way" is a setting. Where it is ambiguous, look at the device. A restriction under management control usually shows as a greyed-out toggle the user cannot change; a setting shows as a specific value.
Yes. Files that never reach the record never appear on the removal checklist, so they never get cleared. The shared signature of this residue is a clear purpose at install time, nobody owning the removal, and discovery only after the device has moved on.
Three fields per file: signer, install time, payload class. The file count per device is small. What is heavy is the absence of the record, because that cost is paid later by opening each device by hand.