ServiceNow and Microsoft Intune Integration Guide

The ServiceNow and Intune integration keeps device records aligned between the two platforms. When a device is enrolled in Intune it is registered in ServiceNow as a configuration item, and when it is unenrolled it is marked inactive. Attributes such as model, OS version, owner and serial number sync from Intune to ServiceNow.

Device Inventory and Asset Synchronisation

Microsoft Intune manages enterprise mobile devices, laptops, and PCs. ServiceNow must maintain a current device inventory for asset management, incident assignment, and compliance tracking. Intune integration synchronises devices between Intune and ServiceNow: when a device is enrolled in Intune, it’s registered in ServiceNow as a CI (configuration item). When a device is unenrolled, it’s marked inactive in ServiceNow. Device attributes (model, OS version, owner, serial number) sync from Intune to ServiceNow, providing a unified view of enterprise devices.

This synchronisation ensures that when an incident is reported by a user (e.g., “my laptop won’t connect to Wi-Fi”), IT can quickly query ServiceNow to find which device the user owns, pull device details from Intune (OS version, patch level, policy compliance), and correlate with known issues. Without synchronisation, support staff must manually lookup device information or contact users for device details, delaying issue resolution.

Mobile Device Provisioning and OnBoarding Requests

When a new employee is hired, their manager may request a mobile device (iPhone, iPad, Android) as part of onboarding. ServiceNow Request Fulfillment captures the device request (type, model, accessories), routes it for approval, then triggers Intune provisioning. Intune automatically enrolls the device in mobile device management (MDM) and applies corporate policies: email configuration, app deployment, encryption settings, and compliance rules. The provisioned device is shipped to the employee or can be picked up from IT. ServiceNow tracks the request status so managers know when devices will arrive.

Policy configuration in Intune determines what capabilities devices have: which apps are available, whether user can install apps, whether corporate data is encrypted, and whether device must have a PIN lock. Some organisations apply different policies to different device types: executive devices may have fewer restrictions than contractor devices. Build device request workflows to capture intended policy level and route to Intune automation that applies appropriate policies.

Compliance Reporting and Non-Compliant Device Escalation

Intune continuously monitors devices for compliance with corporate policies: devices must have current OS patches, encryption enabled, PIN locks configured, and approved antivirus running. When a device becomes non-compliant (e.g., an employee disables encryption or doesn’t patch), Intune reports the non-compliance to ServiceNow. ServiceNow can automatically create a compliance incident or ticket for the device owner, asking them to remediate. If the device is not remediated within a defined timeframe, Intune can block access to corporate resources or reset the device to enforce compliance.

Track non-compliance trends: if certain device models or OS versions frequently become non-compliant, investigate root cause and adjust policies or provide targeted user training. Some compliance failures are due to policy conflicts (update schedule conflicts with usage patterns) or user behaviour (disabling features to extend battery life); understanding root cause helps address compliance without overly restrictive policies.

Incident Response and Device Isolation

When a device is suspected of security compromise (malware detected, credentials exposed, unusual activity), Intune can isolate the device: revoke network access, disable cloud app access, and quarantine for investigation. ServiceNow should receive incident notifications when Intune detects security threats and should coordinate with security teams. If a device requires isolation, ServiceNow can notify the device owner (their device is quarantined for security investigation) and provide instructions for remediation (run antivirus, change password, contact IT). Once the device is verified clean, Intune removes the quarantine and restores full access.

Configure escalation workflows for security incidents: if a device has high-risk malware, escalate to security operations immediately. If antivirus found and cleaned malware, escalate to IT operations. If user reports unusual device behaviour, escalate to security for investigation. ServiceNow workflows can route incidents to appropriate teams based on threat severity and type.

Device Retirement and Decommissioning

When a device reaches end of life (hardware failure, OS no longer supported) or an employee leaves, Intune must retire the device: revoke all access, remove from management, and wipe corporate data. ServiceNow should track retirement status: when an employee is terminated or a device is marked for retirement, trigger Intune decommissioning. After wiping, the device should be securely disposed of or repurposed. Track retirement requests and completions in ServiceNow so IT can confirm devices are no longer in circulation and corporate data has been removed.

Set up alerts for end-of-support dates (when OS versions will no longer receive patches) and end-of-life dates for hardware. As these dates approach, trigger device replacement requests in ServiceNow so users receive new devices before old ones are unsupported. Proactive replacement is better than facing a large fleet of unsupported devices.

Integration Configuration and Device Identifier Mapping

Intune and ServiceNow use different device identifiers. Intune uses device ID, serial number, and Entra (Azure AD) object ID. ServiceNow uses asset tag, serial number, and asset ID. Map identifiers carefully so records sync correctly: if Intune and ServiceNow disagree on which device is which, synchronisation breaks and duplicate records accumulate. Serial number is the most reliable common identifier; use it as the primary sync key and validate that serial numbers match between systems.

Configure sync frequency: devices should sync at least daily, but hourly sync is better for rapid detection of new devices or compliance changes. During large onboarding events (hiring sprees, store openings), sync volume may spike; monitor sync performance and adjust intervals if needed. After initial sync setup, monitor data quality: spot-check a few device records to confirm attributes match between Intune and ServiceNow.

User Communication and Self-Service Capabilities

Device owners need visibility into their device’s compliance status. Some organisations provide a self-service portal where users can see their enrolled devices, check compliance status, and request device actions (lock, wipe, locate). ServiceNow or Intune can provide this portal. If a device is non-compliant, users should understand why and what they need to do to fix it. Provide clear guidance: “Your device is non-compliant because: Windows update pending. To resolve: go to Settings, Windows Update, and install updates, then restart.” Clear guidance drives compliance without requiring support team intervention.

Matching Intune devices to asset records and deciding who acts on non-compliance

An Intune link has two jobs that are easy to blur: keeping the device record accurate, and deciding what happens when a device stops meeting policy. The first is a matching problem. Intune, the asset register and the CMDB each identify a device with a different key, and the link works only when those keys agree. The second is a responsibility problem. A non-compliant device might belong to a user who needs a prompt, a support engineer who needs a task, or a security team that needs an incident. Settle both before the first sync.

Serial number is usually the most dependable common key, but it is not always unique. Virtual devices, re-imaged hardware and some older models can share or lack a serial. Decide in advance what the link does with a device that matches on serial but disagrees on owner, and with a device that matches nothing. Those two cases can generate much of the manual work in the first months.

Decision table for compliance states

An order of work for the first device sync

1. Agree the identifier hierarchy: serial number first, then a second attribute for the exceptions, and a manual review path for anything left over.
2. Run the sync against a test group of devices and compare the matches with the physical asset register.
3. Check how retired devices are recorded, because a device that was wiped and reissued is the most likely source of duplicates.
4. Switch on compliance events for one policy first, so the service desk learns the messages before the volume grows.
5. Add isolation and retirement workflows last, after the approval and communication steps have been tested with a dummy device.

Give the device owner a clear message

Much non-compliance is fixed by the person who holds the device, and only if they understand what is wrong. A task that says the device is non-compliant, without naming the setting or the step, generates a support call. Write the message from the policy’s perspective: which setting failed, what the person must do, and how long they have before access is affected. Keep the wording consistent across policies so people recognize the pattern.

The request fulfillment and service catalog design is useful here when remediation needs a request, such as a replacement device or an exception to a policy. Exceptions should expire, and the record should show who approved them and until when.

Signs the device link is reliable

• Devices that were enrolled and then retired show a retired state and a date, and do not appear as active assets.
• Non-compliance tasks reach the owner the same working day the state changes.
• Isolation events create a security incident and notify the device owner with plain instructions.
• Exceptions show an approver and an expiry date.

Retirement and offboarding

When an employee leaves, the device has to come back and be wiped in a sequence that does not lose the record. Trigger the retrieval task from the leaver process, not from the device, so the people responsible for the handover can see it. The link should record the wipe outcome against the asset, and for how the leaver steps connect, the employee offboarding controls guide is the place to look. A device that is wiped but never recorded as returned is a loss of control, even when the data is gone.

What is the best key for matching a device across the two systems?

Serial number, used with a second attribute to resolve duplicates and blanks. Device identifiers from the management platform can change when a device is re-enrolled, which makes them a weak primary key for the asset record.

Should a non-compliant device be blocked automatically?

Blocking access is a policy decision for the security owner. The ServiceNow side should show the block, the reason and the owner’s response, so that a blocked user is not left without a path back.

How do we handle a device used by several people?

Record the device owner as the accountable person and keep a separate list of approved users where the policy requires it. Do not guess the current user from the last sign-in, because that value is often stale.

Can the device self-service portal replace the service desk?

For simple, repeatable fixes it can, and it reduces tickets. Keep the service desk path for anything that needs an exception, a replacement or a judgment about risk.

Next step

If compliance events are already reaching the service desk without a plan for them, a short review will show where the routing should change.