Android Enterprise QR Code Enrollment: What's Inside, How to Guard It

QR code enrollment is a common way to bring a company Android device under management. You factory-reset the phone, tap the welcome screen, point the camera at a printed square, and a few minutes later the device is enrolled, configured, and has its apps. No account to type, no long setup checklist, no cable.

That convenience comes from what the code contains. An Android Enterprise QR code is not a pointer to a web page. It is a small configuration file that tells the device which management app to install, which organisation it belongs to, and sometimes which Wi-Fi network to join and with what password. Anyone who can photograph the code can read that file, and anyone holding a valid copy can enroll a device into your fleet.

This guide is for IT leads who enroll company Android devices with QR codes, at a desk or in the field, and who may need to explain the process and its risks to directors. It starts with what the code carries, then covers the choice between company-owned and personal use, Wi-Fi in the code, access to the code, and what to do when a code leaks. It ends with how QR enrollment compares with zero-touch and Knox Mobile Enrollment, plus a short troubleshooting section that covers the "enrollment token expired" problem.

The Basics: What QR Code Enrollment Actually Does

Some vocabulary first, because the rest of the article depends on it.

• Enrollment (or provisioning): the process that turns a new or factory-reset device into a managed device. During provisioning, a management app is installed and given administrative rights over the device or over a part of it.
• Device policy controller (DPC): the management app on the device that applies your organisation's rules. With the Android Management API, Google's API for managing Android Enterprise devices, the DPC is Google's Android Device Policy app.
• Enrollment token: a string issued by your management platform that identifies which organisation and which policy a new device should join. It works like an invitation code.
• Setup wizard: the first-run screens Android shows after a factory reset (language, network, accounts).
• Policy: the set of rules, apps and settings the management platform applies to a device: passcode requirements, allowed apps, Wi-Fi networks, kiosk mode, and so on.

The six-tap flow

On a factory-reset device running Android 7 or later, tapping the welcome screen six times in the same spot opens a QR code scanner. On some older Android versions, the device first asks to connect to a network so it can download a QR reader. Newer versions have the reader built in. Once the code is scanned, the device:

1. Reads the provisioning payload stored in the code.
2. Connects to the network, using the Wi-Fi details in the code if they are present.
3. Downloads the DPC and checks its signature against a checksum in the payload, so a tampered app is rejected.
4. Hands the enrollment token to the DPC, which presents it to the management service.
5. Receives the policy linked to that token and applies it: restrictions, apps, networks, kiosk settings.

Where "afw#setup" fits

The afw#setup method and the QR code are often mentioned together. They are separate entry points to the same result. afw#setup is a DPC identifier: you type it into the Google account field of the setup wizard instead of an email address, and the device downloads Android Device Policy. That app then asks for the enrollment token, usually by scanning a QR code or typing the code. The six-tap method gets the same information in one scan. Either way, the enrollment token is the part that decides which organisation the device joins.

What Is Inside the Code

A QR code is a way of encoding text as an image. It does not encrypt anything. Any QR reader app, including the camera on most phones, can turn the picture back into the original text. For Android Enterprise provisioning, that text is a JSON document. JSON is a plain, human-readable format of keys and values.

Below is an illustrative payload using the keys Google documents for Android Management API provisioning. Your management platform builds the real one, and the exact fields depend on your settings.

{
  "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":
      "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
  "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":
      "<published checksum of the DPC>",
  "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION":
      "https://play.google.com/managed/downloadManagingApp?identifier=setup",
  "android.app.extra.PROVISIONING_WIFI_SSID": "Staging-Net",
  "android.app.extra.PROVISIONING_WIFI_PASSWORD": "example-password",
  "android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE": "WPA",
  "android.app.extra.PROVISIONING_TIME_ZONE": "America/Sao_Paulo",
  "android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED": false,
  "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
    "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "<enrollment token>"
  }
}

Here is what each group of fields does and how sensitive it is.

Two fields matter most: the token and the Wi-Fi password. The rest of this article is about handling them.

Company-Owned or Personal Use: Why It Is Decided at Enrollment

Android Enterprise has several management modes, which define how much of the device the organisation controls.

• Fully managed (company-owned): the DPC becomes the device owner and manages the whole device. This suits shared devices, rugged scanners, kiosks and dedicated work phones.
• Company-owned with personal use allowed: the organisation owns the device and controls its overall security, and the user also gets a separate personal space. Work apps and data sit in a work profile, a sandboxed container with its own apps and data that IT manages. The personal side stays private.
• Work profile on a personal device (BYOD): the employee owns the device. The organisation manages only the work profile and cannot see or wipe personal data.

Why you cannot simply switch later

Outside developer test setups, Android grants the device owner role only during initial setup, from a factory-reset state. That is why company-owned enrollment starts from the welcome screen. For the same reason, the mode is effectively fixed once the device is enrolled. Moving a device from fully managed to a work-profile arrangement, or the reverse, generally means a factory reset and a new enrollment. That costs time, and on a personal device it is unacceptable to the owner.

Make the decision before the first device is scanned. Some practical rules:

• If the device is shared, used in a kiosk, or runs one line-of-business app, choose fully managed.
• If the company buys the phone but employees will reasonably use it for personal calls and apps, consider company-owned with personal use allowed, so the boundary is clear from day one.
• If employees bring their own phones, use a work profile. It is enrolled from the already set-up device through a link or code, not through the six-tap welcome-screen flow.

The QR code carries this decision with it. A code built for fully managed use will set up fully managed devices for whoever scans it. Name and file your printed codes so that a staging technician cannot pick up the wrong one.

Wi-Fi in the Code: When It Helps and What to Avoid

A device cannot download its DPC without a network connection. You can either let the technician pick a network on the device, or put the network into the QR code.

When it helps

Putting setup Wi-Fi in the code is useful in the field and at volume. A technician enrolling twenty handhelds in a stockroom, or a store manager setting up a replacement tablet, does not have to type a long password on a small keyboard twenty times. That removes typing errors, stops people asking colleagues for the password, and makes the process repeatable enough to hand to non-IT staff. On devices without a convenient keyboard, such as rugged units in gloves-on environments, it can decide whether enrollment is practical at all.

What to avoid

The password sits in the code in plain text. Anyone who scans the code with an ordinary phone camera can read the SSID and password, without enrolling anything. So the Wi-Fi password lasts only as long as the least careful copy of the code. Risky patterns include:

• A one-off code containing a corporate Wi-Fi password, printed on a poster in a stockroom, break area or back office. Visitors, contractors and delivery drivers can photograph it.
• Reusing your main corporate network as the setup network. Leaking the code then means leaking access to everything on that network.
• Codes that outlive the password policy. If the network password rotates but old printouts remain, the result is confusion and, sooner or later, someone "fixing" it by printing a new code with the new password.

Good practice

• Use a dedicated provisioning network: segmented, with internet access only to what enrollment needs, and with a password you are prepared to rotate.
• Prefer a code whose Wi-Fi comes from a network already defined in the policy, so the credentials are managed in one place rather than typed into ad-hoc codes.
• Where you need a one-time exception, such as a customer site with its own guest network, use a code you do not save, and destroy it after use.
• Keep certificate-based enterprise Wi-Fi (802.1X) for the policy that applies after enrollment, not the setup payload. A simpler, isolated staging network is easier to support during setup.
• If a site has mobile data or Ethernet, consider leaving Wi-Fi out of the code entirely.

Nomid's enrollment screen follows this split. The standard QR code for a policy takes its setup Wi-Fi from a network that already belongs to the policy, with the password taken from the policy. A separate "Use a different Wi-Fi once" option creates a one-off code that is not saved, and the portal warns that anyone with the QR code can read the password.

Treat the Code Like a Key

The "skeleton key" metaphor is useful, but it is worth being exact about what the key opens, so the risk is neither inflated nor dismissed.

What a leaked code can and cannot do

A valid enrollment token lets someone add a device to your fleet under the policy linked to that token. That device can then receive whatever the policy delivers, which may include:

• Your private or internal apps, distributed through managed Google Play or a private app store.
• Network configurations, including Wi-Fi credentials the policy pushes after enrollment.
• Web links, files and content intended for staff.
• Any VPN or certificate settings the policy contains.

It also adds an unknown device to your inventory, which pollutes reporting and can use up licences.

What the token does not do is give access to your management console, to existing devices, or to their data. It is a key to the front door of enrollment, not to the control room. That distinction matters when you explain an incident to directors. The exposure is limited to "what any enrolled device in that policy receives", plus the Wi-Fi password if one was in the code.

Who can create and print it

Treat enrollment codes like other credentials, with least-privilege access. Ask:

• Which console administrators can see a policy's enrollment code at all?
• Who can regenerate it?
• Do regional or site administrators need codes for every policy, or only for the policies their sites use?

In Nomid, administrators without provisioning permission on a policy cannot see its enrollment codes, and regenerating a code requires permission to edit the policy. Role design is therefore the first control. Give store or field leads provisioning rights only for the policies they actually enroll into.

Where it ends up

A leak does not need an attacker. Often the code simply travels further than intended. Common routes:

• Photos. A technician photographs the code "to have it handy", and it ends up in a cloud photo backup or a shared album.
• Chat groups. A code shared with one colleague is forwarded to a regional group, then a supplier group.
• Posters and printouts. Codes taped to walls, left in staging rooms or filed with shipping paperwork.
• Screenshots in tickets and documentation. Help-desk articles, slide decks and onboarding guides that include a live code.
• Email invites. Forwarded beyond the intended recipient.

Practical habits:

• Share codes with named individuals, not groups, and prefer showing the code full-screen on a laptop during a staging session over handing out paper. Every other way of sharing leaves a copy behind: in Nomid that means a downloaded image, a printout, a copied link, a WhatsApp message or an e-mail invite.
• Collect and shred printouts after a rollout.
• Use placeholder images in documentation, never a live code.
• Keep a short record of where each policy's code has been shared, so you know the blast radius if you need to regenerate.

Expiry

Enrollment tokens have a validity period. After it ends, codes and links built on the token stop enrolling devices. This limits how long a forgotten printout stays dangerous, but it also explains why a code that worked last quarter can fail today. How long a token stays valid depends on how your platform issues it. Rather than relying on a figure from memory, check the expiry your console shows and plan rollouts around it. Nomid's enrollment screen shows "Valid until <date>" and "Last regenerated" for each policy's token.

Expiry is a backstop, not a substitute for regenerating. If you know a code has leaked, do not wait for it to expire.

A Code That Leaked: Regenerate, and What Happens Next

Suppose a staging code was posted in a chat group with external contractors, or a poster stayed on a wall after a store refit. Work through the following steps.

1. Regenerate the token

Regenerating issues a new enrollment token for the policy and invalidates the old one. In Nomid, "Regenerate QR code" on the policy's Enroll devices screen requires permission to edit the policy. The admin must confirm "I understand that old QR codes and links stop working" before it proceeds.

2. Understand what stops working

Because every QR code and enrollment link of a policy carries the same token, regenerating affects them all at once. After regeneration in Nomid:

• Every QR code of that policy stops working, including printed ones, downloaded images and screenshots.
• Every enrollment link stops working, including links shared by chat or copied into documents.
• Every emailed invite for that policy stops working.

This is intended, but it has an operational cost. Any site with a legitimate printout will need the new code. Tell field teams before you regenerate, or immediately after, and send replacements through a narrower channel than the one that leaked.

3. Why enrolled devices keep working

Administrators often worry that regenerating will knock existing devices off management. It will not. Each device presents the enrollment token once, at the moment it joins (the same token can admit further devices until it expires or is regenerated). After that, the device has its own identity and relationship with the management service and does not refer back to the token. Regenerating changes the invitation, not the membership. In Nomid, enrolled devices are not affected by regeneration.

4. Check for zero-touch dependencies

If a zero-touch configuration uses the policy's token, regenerating would quietly break every future zero-touch device assigned to that configuration. Nomid prevents this: the portal refuses to regenerate until the zero-touch configuration points elsewhere. Reassign that configuration first, then regenerate.

5. Clean up after the leak

Regenerating stops new enrollments. It does not undo ones that already happened. Follow up by:

• Reviewing devices enrolled into that policy since the leak may have happened, and looking for names, models or locations you do not recognise.
• Removing or wiping any device you cannot account for.
• Rotating the Wi-Fi password if the leaked code contained one, because regenerating the token does nothing for a password that has already been read.
• Reviewing what the policy distributes. If it hands out sensitive configuration, consider whether that belongs in a more restricted policy.

For directors, the short version is: "We revoked the code, existing devices were unaffected, we checked for devices that should not be there, and we rotated the network password."

QR vs Zero-Touch vs Knox Mobile Enrollment

QR codes are one of several enrollment routes, and each has a place. Android zero-touch enrollment links devices to your organisation at purchase through a participating reseller. The device enrolls itself on first boot with no scanning, and there is no printed code to leak, but it depends on buying through a zero-touch reseller. Samsung Knox Mobile Enrollment offers similar automatic enrollment for Samsung devices, with devices registered through Samsung's portal or a participating reseller. QR enrollment works on almost any Android 7+ device you already own, from any source. That makes it the practical option for mixed fleets, re-enrollment after repair, and small batches, at the cost of handling the code carefully. A sensible split is zero-touch or Knox for new purchases and QR for everything else.

Troubleshooting Common QR Enrollment Problems

"Enrollment token expired" or "invalid token"

The token has passed its validity period or has been regenerated, so the code is no longer valid. That is the first thing to suspect when an old printout or saved screenshot fails. Get the current code from the console and check its expiry date. If the code has been regenerated recently, any copies made before that date will fail by design.

Tapping the welcome screen does nothing

Make sure the device has been fully factory-reset and is on the very first welcome screen, and tap six times in the same spot. Some older Android versions need a network connection to download a QR reader first. If the device has already passed the welcome screen, company-owned enrollment requires another reset.

The device scans the code but cannot connect

Check that the setup network is in range and that its password has not changed since the code was created. Check also that the security type is one the setup payload supports. Captive portals, the sign-in pages common on guest networks, will block provisioning. Use a network without one.

The device enrolled with the wrong mode

The device was scanned with a code built for a different usage type or policy. Because the mode is set at enrollment, the fix is to remove the device, factory-reset it, and enroll it with the correct code. Label printed codes clearly to avoid repeats.

Enrollment succeeds but apps are missing

Apps can take time to download after enrollment, especially on slow networks. Confirm the device has a stable connection and that the apps are assigned in the policy. On Nomid-managed devices, the Nomid Settings app includes a Check-up screen, if the policy shows its button. It checks that the policy's Nomid Store apps are installed, that the device can reach the Nomid API and remote access servers, and that Play Store, Google Play Services, location services and agent permissions are in order. Failed checks offer a fix, and the run is recorded in the device's command history.

Putting It Together

An Android Enterprise QR code is a readable configuration file printed as an image. It names the management app, carries an enrollment token that admits devices to a specific policy, and can include setup Wi-Fi with its password in plain text. That is why it speeds up enrollment, and why it needs the same care as any credential.

Key takeaways:

• Know what is in your codes. The enrollment token and any Wi-Fi password are the sensitive parts.
• Choose the management mode (fully managed, company-owned with personal use, or work profile) before enrollment. Changing it later usually means a reset.
• Put Wi-Fi in the code to remove typing on site, but use a dedicated, segmented provisioning network, and do not post one-off codes containing passwords.
• Limit who can view and regenerate codes, share them with named people rather than groups, and collect printouts after rollouts.
• Watch the token's validity date, and do not wait for expiry once you know a code has leaked.
• When a code leaks: regenerate, reissue codes through a narrower channel, check for unknown devices, and rotate any exposed Wi-Fi password. Enrolled devices keep working.
• Use zero-touch or Knox Mobile Enrollment where your purchasing supports it, and QR for everything else.

Next steps: list every enrollment code currently in circulation: printouts, screenshots, chat messages and documentation. For each one, note the policy it belongs to and whether it contains a Wi-Fi password. Then decide which codes to regenerate now and which to leave until they expire.

If you are evaluating platforms, Nomid MDM puts these controls on each policy's Enroll devices screen:

• One QR code per policy, built from the policy's saved defaults (usage type, time zone, a policy Wi-Fi network and provisioning options).
• A clearly marked one-off option for a different Wi-Fi network.
• Work profile links for personal devices where the policy allows it.
• Visible "Valid until" and "Last regenerated" information.
• A regenerate action that requires confirmation and checks zero-touch dependencies first.

Zero-touch, Knox Mobile Enrollment and the enrollment token itself are offered as alternative routes. A free plan covers up to 10 devices with no time limit, which is enough to test your enrollment process and code handling before rolling it out more widely.