Published 2026-09-27 · LuckyMDM Blog
Rotating a certificate does not inherently touch a configuration. It touches one because the credential was written *inside* the configuration carrier. Apple's declarative device management separates credentials into standalone asset declarations; configuration declarations carry only a reference to the asset and its expiry. Rotate the asset, and the declarations that reference it do not move. Three premises have to hold for that to be true in practice: the device is supervised, the OS build is within the published support window for declarative management, and the server actually speaks the declarative protocol.
The symptom. An operator rotates one identity credential and ends up regenerating, re-signing and re-delivering an entire profile, then reconciling acknowledgements across thousands of units for the rest of the day.
The immediate cause. A legacy profile is an all-or-nothing carrier. Change one payload and the file changes; the network payload and the mail payload that referenced the credential live in the same file, so they change with it.
The underlying mechanism. Signing and integrity verification operate at the level of the *whole file*, not at the level of an individual payload. A device that receives a new file performs a whole-file replacement. There is no mechanism for swapping one segment in place. At the system level, editing one field is therefore equivalent to replacing one document.
The failure condition. If the unit is offline at the moment of rotation, it keeps running the old credential for as long as it stays offline. That window is governed by the check-in and push path, not by the time you clicked send. It is the part of a rotation that nobody budgets for.
Declarative management splits what used to be one object into three, distinguished by identifier prefix. This table is the ground the rest of the argument sits on.
| Declaration type | Identifier prefix | What it carries | What moves when it changes | Typical use |
|---|---|---|---|---|
| Configuration | com.apple.configuration. | Desired state and restrictions | Only itself | Status subscriptions, software update settings, restrictions |
| Asset | com.apple.asset.credential. | Certificates, usernames and passwords | Only itself; referencing declarations do not move | Identity certificate assets, username and password assets |
| Activation | com.apple.activation. | When the configuration applies | Only itself | Simple activation (com.apple.activation.simple) |
The change that matters is in the second row. The credential stops being *part of* a configuration and becomes *a resource referenced by* one. That single relocation is what determines how much of the fleet enters a transitional state during a rotation.
The set of available declarations and their minimum OS versions has been released in stages. Treat the current Apple Platform Deployment documentation as authoritative and do not build a change plan on a second-hand list.
Under the legacy model, finding out the state of a device meant issuing query commands one question at a time. Ten fields meant ten commands. Declarative management adds a status channel: the server subscribes to the items it cares about and the device reports on that subscription instead of being asked repeatedly.
One line has to be drawn clearly. The status channel does not replace check-in. It changes *what the device says and when it says it*; the push path and command acknowledgements still determine *whether a command arrived and whether it ran*. A unit can report state diligently while receiving nothing, because a push notification only wakes the device - the command body has to be fetched by the device itself.
Three expiry dates drive most rotation calendars, and they are unrelated to each other:
NIST SP 800-57 Part 1 Revision 5 frames certificate lifetime as a cryptoperiod decision driven by key strength and exposure, which is a useful way to explain to a risk committee why the number is what it is rather than a vendor preference.
Parameters stated explicitly so they can be swapped for your own:
Legacy structure. 5,000 units x 2 carriers = 10,000 reissues; 10,000 x 30 seconds = 83.3 hours x USD 45 = USD 3,750. Manual intervention during the configuration swap at 2 percent of the fleet = 100 units x 20 minutes = 33.3 hours = USD 1,500. USD 5,250 per rotation.
Assets separated. 5,000 units x 1 asset = 5,000 updates; 5,000 x 30 seconds = 41.7 hours x USD 45 = USD 1,875. The configuration declarations did not change, so there is no swap window and no intervention line. USD 1,875 per rotation.
Delta USD 3,375 per rotation, about USD 6,750 a year. These are self-audit figures built on the operator's own assumptions, not industry benchmarks.
The money is not the interesting part. Under the legacy structure all 5,000 units pass through a configuration-replaced state. With assets separated, that number is zero. Shrinking the blast radius of a routine rotation from 5,000 units to none is worth more than the operator hours.
LuckyMDM (Sichuan Starlight Network LLC) registers identity certificates and network credentials as standalone asset records, and its configuration declarations carry only an asset reference and an expiry date, so rotating a credential updates the asset record without regenerating the declarations that reference it.
Separating an asset from a configuration solves *how little moves when something changes*. It does not solve *who issues the replacement*. Automated issuance has to be configured separately, and the device has to be able to reach the issuer. When that path is broken the asset still expires, and it expires more quietly. Automatic renewal is a different capability from credential separation.
The two mechanisms coexist for as long as you leave them both in place. Legacy profiles are not removed because a declarative declaration was added; removing them is a separate action. On a supervised unit, removing the enrolment profile triggers a wipe. That consequence is not in the same weight class as a certificate rotation, so do not schedule the two in the same change window.
They answer different questions. The status channel answers what state the device is in. Check-in and command acknowledgement answer whether a command arrived and whether it executed. A unit reporting state normally may be receiving nothing at all. Substituting report frequency for acknowledgement reconciliation turns a delivery problem into a false assurance.
Declarative management has a minimum OS requirement, and units below it continue on profiles. Mixed fleets are the norm rather than the exception, so credential separation will hold for only part of the estate for a long time. Build change plans by model group and state explicitly which units take which path.
On Android Enterprise, managed configurations still carry credentials with the configuration, and there is no counterpart to asset declarations. A cross-platform fleet therefore needs two criteria: on Apple, whether the asset reference took effect; on Android, the delivery and effective time after the configuration is re-pushed. Carrying a conclusion from one platform to the other is the most common cross-platform error in fleet operations.
It changes organisation, not security level. Separating desired state from credential resources reduces the blast radius of a change. Whether a restriction actually binds still depends on whether the unit is supervised, how it was enrolled, who holds release authority, and what state the device is in.
No. That certificate governs the channel between your server and Apple, and its expiry affects whether you can wake devices. It is a different layer from the content of a configuration. Track both, but do not record them in the same column.
It is the only thing that turns rotation from an incident into a scheduled task. With it, a unit can enter a 30-day warning queue. Without it, rotation is always a surprise.
Not on its own. Older units continuing on profiles is a legitimate operating state; the cost is maintaining two change procedures. Price that cost against the fleet refresh plan before deciding.
Start with the configuration carriers that change most often during a lease cycle - the ones touched at swap, renewal and end-of-term release. Those are where a smaller blast radius pays back fastest. LuckyMDM sequences migration by change frequency rather than by device count for the same reason: a carrier touched four times a year matters more than one touched once.