Android and iOS: provisioning, enrolment, and what a reset destroys

Why this matters

Mobile devices are where the gap between "I fixed it" and "I destroyed something" is narrowest. A reset takes four taps, finishes in two minutes, and is irreversible in a way almost nothing else in this exam is. The data is usually the only copy, the account attached to it may be the only route back in, and the person handing you the phone rarely understands either of those things.

This is also the lesson with no hands-on lab, for exactly that reason: the exercise would be a factory reset, and most readers have one phone. The applied lab plans a reset instead, which is the form the exam asks in and the form the job asks in — the skill being examined is knowing what to capture first, not knowing where the button is.

The lesson

Out-of-box setup, and the account that becomes the device's identity

Out-of-box setup asks a handful of questions, and one of them quietly decides everything else: which account the device belongs to.

On both platforms that account becomes the device's identity. It holds the backups, it holds the purchase history, it is the recovery route for a forgotten passcode, and — the part people underestimate — it is what binds the hardware itself. A device signed in to an account is a device that account can find, lock, and erase remotely, and that no one else can activate after a wipe.

The other setup choices worth understanding:

• Restore from backup or set up as new. Restoring brings settings, layout, app list and data; setting up as new brings nothing. A device being restored from a backup made on a compromised device brings the problem with it, which matters in the security objectives.
• Transfer from another device does the same thing directly between two devices in the room, which is faster and avoids a cloud round trip.
• Biometrics and passcode, which can be added later but almost never are if skipped now.

The practical support point: when someone hands you a phone to set up, the first question is whose account it will use, not which apps they want. An account chosen carelessly at setup — a personal account on a work phone, or a shared family account on a personal one — produces problems that only surface months later, when the wrong person can erase the device or the right person cannot.

Enrolment and mobile device management, and what accepting a profile grants

Enrolment is how an organisation takes some control of a device, and what it grants is worth being able to describe honestly.

Mobile device management works through a profile the device installs. Once installed, the management server can typically:

• Require a passcode of a stated complexity, and lock or wipe the device.
• Install and remove applications, and block the app store.
• Configure mail, wireless and VPN, and remove those configurations.
• Restrict features — the camera, screenshots, backups to a personal account.
• See an inventory of what is installed, and on some platforms rather more.

What it usually cannot do, which users assume it can: read personal messages and photos on a personally-owned device under the normal enrolment mode. The honest answer to "can they see my photos" is "not under this kind of enrolment", followed by what it can do, because a vague reassurance is worse than a specific one.

Two distinctions the exam likes:

• Corporate-owned enrolment is deeper than personal-device enrolment. On a corporate device the organisation can usually wipe everything; on a personal one it wipes only the managed work area.
• A profile is consent. Accepting it is an action the user takes, and removing it usually removes the work data with it. A user who removes a profile to "clean up" and loses their work mail has not broken anything — they have triggered the designed behaviour, and the explanation is the fix.

Activation lock and factory reset protection, and the machine you cannot rescue

This is the single most expensive thing in this objective, and it is a security feature working exactly as intended.

Activation lock and factory reset protection tie a wiped device to the account that was on it before the wipe. After a reset, the device asks for those credentials before it will finish setting up. Without them, the device is a paperweight.

The behaviour to internalise:

• The lock survives a factory reset, a recovery-mode restore, and a firmware reinstallation. It is not stored in the part of the device a wipe touches.
• It is not defeated by the passcode. Knowing how to unlock the screen tells you nothing about the account.
• There is no support route that bypasses it on request. The vendors' process requires proof of purchase and takes time, and it exists for stolen devices rather than forgetful ones.

Where technicians create this problem themselves: resetting a device to solve a software fault without first confirming that the customer knows their account password. The device was working; now it is locked; and the technician did it. The rule follows directly — confirm the account credentials before the reset, not after, and if the customer cannot produce them, the reset is not an option that is available to you.

The right way to remove the lock is from the device itself before wiping, by signing out of the account, or remotely from the account's own device list. Both need the credentials, which is the point.

Backups: what is actually in one, and what never leaves the device

People believe they have a backup far more often than they do, and the gap is specific enough to be worth learning.

What a normal cloud backup contains: device settings, home screen layout, the list of installed applications, application data for apps that opt in, messages, and photos if photo sync is enabled.

What it frequently does not contain:

• Content already stored in another service, which is restored by signing in rather than from the backup — mail, streaming libraries, some document stores.
• Data from applications that opted out of backup, which includes many messaging and authenticator apps.
• Multifactor authenticator seeds, on some platforms and some apps. This is the one that hurts: a restored phone that cannot generate codes for accounts whose recovery requires those codes.
• Anything at all, if the backup stopped working months ago because the free storage quota filled up. This is extremely common and the device says so quietly.

So the pre-reset check is not "do you have a backup" but "when did the last backup complete, and what is in it". The date is on the same settings screen as the switch.

The professional habit: before any reset, capture the authenticator situation explicitly. Moving authenticators is a separate job with its own steps, and doing it after the wipe is impossible.

Resetting a device properly before it changes hands

A device changing hands — sold, returned, reassigned — needs more than a reset, and the order matters.

The sequence that works:

1. Back up, and confirm the backup completed and is recent.
2. Move authenticators to the new device or to recovery codes.
3. Sign out of the account on the device, which is what clears activation lock and factory reset protection.
4. Remove any management profile, if it is a work device being released.
5. Remove the SIM or eSIM, and on a cellular device remove it from the carrier account too.
6. Factory reset from the device's own settings, not from recovery.
7. Confirm it comes back to the out-of-box screen with no account prompt, which is the only proof that step 3 worked.

Step 7 is the one people skip and the one that matters. A device that asks for an account after the wipe has not been released; it has been made useless to whoever receives it, and they will be back.

For a work device being reassigned, there is an extra consideration from the operational procedures objective: the device may hold regulated data, and a factory reset on a modern device is cryptographic erasure — the key is destroyed and the data becomes unreadable — which is generally accepted as sanitisation. Whether it is accepted in a specific regulated context is a policy question for the organisation, not a technical judgement for the technician, and the right move is to ask rather than to assume either way.