Fix Intune Enrollment Error 0x80180018 on Windows Devices

Intune enrollment error 0x80180018 usually appears when the Windows enrollment flow gets far enough to contact Microsoft services, but the tenant or user is not actually ready to complete MDM enrollment. Microsoft maps 0x80180018 to MENROLL_E_USERLICENSE, which is the important clue: start by proving the user and tenant licensing path, not by rebuilding the device.

In the field, this error often gets mixed up with broader enrollment failures. Admins see a generic Company Portal or Settings app failure and start checking proxies, reimaging devices, or deleting records. That usually wastes time. Microsoft Learn points to a tighter workflow: confirm the user has the right Intune entitlement, confirm automatic enrollment is configured correctly in Microsoft Entra, and verify that you did not accidentally put the same user into a MAM-only path when you expected full MDM management.

This guide is for Desktop Engineers and Intune admins who are troubleshooting Windows enrollment failures in Intune, especially during Microsoft Entra join, work account registration, or Company Portal enrollment.

What 0x80180018 actually means

Microsoft’s MDM enrollment diagnostics table maps 0x80180018 to license error. That does not always mean only one simple thing is wrong, but it does narrow the investigation a lot. In practice, the failure usually falls into one of these buckets:

1. The enrolling user does not have a valid Intune license.
2. Automatic MDM enrollment prerequisites are incomplete, especially Microsoft Entra premium licensing or MDM user scope.
3. The user is landing in a MAM or WIP path on a BYOD device instead of true device management.
4. The enrollment UI shows a misleading MDM Terms of Use message that is still rooted in licensing or bad default MDM URLs.

Microsoft’s Windows enrollment troubleshooting article also documents a related user-facing message: This account is not allowed on this phone. Its stated cause is straightforward: the user who tried to enroll the device does not have a valid Intune license. That is why 0x80180018 should be treated as an entitlement and enrollment configuration problem first.

Fast triage checklist

Use this order before you wipe the device or delete objects from Entra and Intune:

1. Confirm the exact error shown in Windows, Company Portal, or Event Viewer is 0x80180018.
2. Identify the enrolling user and verify whether the failure happens for only that user or for every pilot user.
3. In Microsoft 365 admin center, confirm the user has a qualifying Intune license or Microsoft 365 bundle that includes Intune.
4. In Microsoft Entra, confirm the tenant has the required premium capability for automatic MDM enrollment.
5. Check Microsoft Entra ID > Mobility (MDM and MAM) > Microsoft Intune and verify MDM user scope is set to Some or All for the affected user.
6. If the device is personal or BYOD, check whether the same user is also in the MAM/WIP user scope.
7. Restore and validate the default MDM URLs if the enrollment screen mentions Terms of Use or cannot connect to the MDM Terms of Use endpoint.
8. Confirm the device is using a supported Windows version.
9. Re-test with one known-good licensed pilot user before changing anything tenant-wide.
10. If the issue persists, collect device-side enrollment diagnostics and event logs.

That checklist is faster than broad tenant cleanup because most 0x80180018 cases are resolved on the admin side, not the device side.

Fix 1: Prove the user really has the right license

This is the first check because Microsoft explicitly says the code is a user license error. Go beyond “the admin can sign in to Intune.” Unlicensed admin access does not mean enrollment is licensed for end users.

Microsoft’s licensing documentation says an Intune license is required for any user or device that benefits directly or indirectly from the Intune service. It also notes an important distinction that trips up admins during testing:

• Administrators can access the Intune admin center without an Intune license in supported tenants.
• That does not remove license requirements for enrolled users or managed devices.

Practical checks:

• In Microsoft 365 admin center, open the affected user and verify assigned products.
• Confirm the user has a bundle or standalone entitlement that includes Microsoft Intune Plan 1 where required.
• If you are testing with a service desk or admin account, do not assume portal access equals enrollment rights.
• If the tenant mixes older MDM for Microsoft 365 behavior with Intune, confirm the user is not missing both an Intune license and the relevant Microsoft 365 entitlement.

If you assign or change the license, give Azure and Intune a little time to process the change before retesting. A second attempt made too quickly can look like the fix failed when the assignment simply has not propagated yet.

Fix 2: Check automatic MDM enrollment prerequisites in Entra

A licensed user can still fail enrollment if the tenant is not configured for automatic MDM enrollment.

Microsoft’s automatic enrollment documentation says this feature depends on a premium Microsoft Entra capability. It also requires the MDM user scope to be configured for Microsoft Intune. If the user is out of scope, Windows can register the account without completing the MDM management path you expected.

Check these settings:

1. Open Microsoft Entra admin center.
2. Go to Mobility (MDM and MAM).
3. Select Microsoft Intune.
4. Verify the tenant is configured for Intune automatic enrollment.
5. Set MDM user scope to All or to Some with a group that contains the test user.
6. Save the setting and wait for it to apply.

If your environment uses staged rollout groups, confirm the affected user is really in the in-scope group. A very common failure pattern is that the pilot device is correct but the pilot user was never added to the MDM scope group.

This is also where you separate device management from account-only management. Microsoft explains that MDM user scope controls full device enrollment and management. If it is None, the device is not managed by Intune through this path.

Fix 3: Watch for MAM or WIP precedence on BYOD devices

This is one of the easiest ways to lose time on personal devices. Microsoft documents that if a user is in both the MDM scope and the WIP or MAM scope, the outcome depends on device ownership:

• On corporate-owned devices, MDM takes precedence.
• On bring-your-own Windows devices, the WIP or MAM path can take precedence instead of full MDM enrollment.

That means a user can look “correct” on paper while the Windows device still does not enter the management path you intended.

Use this logic:

• If the device is corporate-owned and meant to be fully managed, keep the user in the MDM scope and review whether WIP or MAM overlap is necessary.
• If the device is BYOD and you expected only app protection, then 0x80180018 may be exposing a mismatch between your enrollment expectation and your tenant scope design.
• If the device is BYOD but you really want full MDM enrollment, make sure the user is in scope for MDM and not accidentally forced into a MAM-first design.

Microsoft’s guidance is clear here: for BYOD automatic enrollment, use All or Some for the MDM user scope and make sure the WIP user scope is None or at least does not include the same users. If the same user is in both places, the device might register the account but never become the fully managed Intune device your workflow expects.

Fix 4: Repair the MDM Terms of Use and default enrollment URLs

Some 0x80180018-adjacent failures do not present the code first. Instead, the user sees a message that Windows cannot connect to the MDM Terms of Use URL. Microsoft documents that this can happen when:

• The tenant uses both MDM for Microsoft 365 and Intune.
• The affected user does not have a valid Intune license or Office 365 license.
• The MDM terms and conditions URL in Entra is blank or incorrect.

That combination matters because admins often chase the URL and miss the licensing root cause.

Check both:

1. In Microsoft Entra ID > Mobility (MDM and MAM) > Microsoft Intune, select Restore default MDM URLs.
2. Verify the MDM terms of use URL is https://portal.manage.microsoft.com/TermsofUse.aspx.
3. Save the configuration.
4. Reconfirm the user license assignment.

If you only fix the URL and leave the user unlicensed, the next attempt may still fail. If you only assign the license and keep a broken MDM URL, the user can still hit a misleading front-end error.

Step-by-step remediation workflow

When a user or service desk ticket lands with 0x80180018, run this workflow in order:

1. Validate the user and the scenario

Record:

• Username and UPN
• Device ownership type: corporate or BYOD
• Enrollment path: OOBE, Settings app, Company Portal, or Entra join
• Exact error text or screenshot
• Whether any other test user can enroll on the same device

If another properly licensed user can enroll but the affected user cannot, your root cause is probably user entitlement or user scope, not the hardware.

2. Confirm the license assignment

Check the user’s assigned products in Microsoft 365 admin center. If the user was just licensed, wait and retest. If you are using group-based licensing, confirm the group assignment completed successfully and there is no conflicting disabled service plan.

3. Confirm MDM automatic enrollment settings

Check the Intune MDM configuration in Entra:

Microsoft Entra ID > Mobility (MDM and MAM) > Microsoft Intune

Verify:

• MDM user scope includes the user.
• WIP or MAM scope is not overriding the intended path.
• Default MDM URLs are present.

4. Verify Windows support and join state

Make sure the device is on a supported Windows version. If the device is hybrid or already partially registered, collect the join state:

dsregcmd /status

You are looking for a broken or partial registration that may confuse the next enrollment attempt, especially if the device was tested several times with different accounts.

5. Collect enrollment diagnostics if the fix is not obvious

Use the built-in diagnostics tool:

mdmdiagnosticstool.exe -area "DeviceEnrollment;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"

Then inspect:

Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin

Look for the enrollment attempt timestamp, licensing-related responses, and any sign that the device registered the account without completing MDM enrollment.

6. Retest with one clean pilot user

After you correct licensing or scope, retest with one pilot user who is known to have the right subscription and group membership. Do not reopen the rollout for a whole department until one device finishes cleanly.

Common causes that look like 0x80180018 but are really admin mistakes

A few enterprise patterns come up again and again:

Admin account can use Intune, so everyone must be licensed

False. Microsoft explicitly separates unlicensed admin access from end-user entitlement. The admin center working tells you almost nothing about a pilot user’s ability to enroll.

User has a Microsoft 365 account, so Intune must be included

Not always. Check the exact license SKU and service plan. Do not rely on role name, department, or an old spreadsheet.

BYOD device should fully enroll because the user is in both MDM and MAM scopes

Not on Windows personal devices. Microsoft documents that MAM or WIP precedence can win there, which means the device can avoid full MDM enrollment.

Portal error mentions Terms of Use, so it cannot be a licensing problem

Also false. Microsoft documents a case where the Terms of Use endpoint message appears when licensing is missing or when the MDM URL is wrong. Check both every time.

Limitations and caveats

0x80180018 is a useful code because it narrows the problem, but it still does not tell you which exact admin setting is wrong. The code can surface through Company Portal, Settings, or a broader join flow, and the user-facing message is not always consistent.

Also be careful with timing after license changes and group updates. A license assignment, MDM scope change, or URL correction may need time to apply across Microsoft 365, Entra, and Intune before the next enrollment attempt is reliable.

If the same device was tested repeatedly with multiple accounts, local registration residue can muddy the picture. In those cases, cleanly remove the work account, confirm the device state, and retest after the tenant-side issues are fixed. Do not make the device your first suspect when Microsoft’s own diagnostics map the error to licensing.

Prevention checklist

Add these checks to your enrollment change process:

• Validate the pilot user’s actual Intune entitlement before testing.
• Document which license SKU satisfies your Windows enrollment scenario.
• Keep a clear rule for who belongs in MDM scope versus MAM or WIP scope.
• Review default MDM URLs after tenant changes or mergers.
• Test one corporate-owned device and one BYOD device when changing enrollment scope.
• Keep a known-good licensed pilot account for fast comparison.

Conclusion

Intune enrollment error 0x80180018 is usually solved from the admin side, not the imaging bench. Microsoft maps it to a user license error, and the surrounding documentation shows the real fix path: verify the user’s Intune entitlement, verify Microsoft Entra automatic enrollment scope, avoid MAM precedence mistakes on BYOD devices, and restore the default MDM URLs when the enrollment screen points at Terms of Use.

Once those pieces line up, the same Windows device that looked broken often enrolls normally on the next clean attempt. Start with licensing and scope, prove the enrollment design, and only then spend time on device cleanup.