When a team decides to roll out ServiceNow Now Mobile with Microsoft Intune, the conversation almost always starts as a UX question — can our field agents approve requests from their phone, can a manager close a ticket at the airport. Somewhere in that conversation, though, it quietly turns into a security question, and it's worth pausing there before a single development story reaches production. Now Mobile isn't the Service Portal squeezed onto a smaller screen. It's a different access channel entirely, and it deserves a different governance conversation.
Why Now Mobile isn't "the portal on a phone"
The native platform UI and the Service Portal both assume the same thing: a browser, a session, and — usually — a device the organization has some visibility into. Now Mobile breaks that assumption. It ships with an embedded MAM SDK so Intune can apply App Protection Policies at the app-container level, which matters enormously for one simple reason: the device underneath that container might not belong to the company at all.
That single fact — the instance data can now live inside an app on a personal phone — is the reason this needs its own governance framework rather than inheriting the web instance's security posture by default.
The first decision nobody writes down: MDM or BYOD?
Every Now Mobile rollout actually splits into two very different risk profiles, and teams often move to production without ever formally choosing between them:
-
Managed devices (MDM) — the device is enrolled in corporate Intune management, so the organization can enforce policy at the full device level, not just inside the app.
-
BYOD (MAM-only) — a personal, unmanaged device where Intune can only govern the app container. Everything outside that container — the camera roll, the OS, the other 40 apps installed — is invisible to your policy.
This isn't a one-time, org-wide setting either — it should be decided per user population, jointly by the business stakeholder who owns the data and the security team who owns the risk. A field technician on a corporate-issued phone and a contractor checking approvals from a personal device are not the same risk, and shouldn't be governed by the same default.
Theft gets all the attention. It's not the only risk.
Ask most stakeholders what could go wrong with mobile access and you'll get one answer: "someone loses their phone." It's a real scenario and it needs a tested runbook — selective wipe for BYOD, full wipe for MDM, a sub-one-hour SLA from the moment loss is reported. But it's genuinely the easy case, because it's visible and it prompts immediate action. The scenarios worth losing sleep over are the quiet ones:
-
A device handed in for screen repair at a third-party shop, sitting unattended with the app still installed.
-
A traded-in or resold phone where nobody triggered a "device retirement" wipe because the device was never technically reported lost.
-
A SIM swap — the attacker doesn't need the phone at all if MFA still relies on SMS.
-
A jailbroken or rooted device that quietly bypasses the OS sandbox the App Protection Policy assumes is intact.
-
Hotel Wi-Fi, airport lounges, "free public charging" kiosks — none of them announce themselves as risky, which is exactly the problem.
-
An employee who leaves the company on Friday but whose app session is still technically valid on Monday, because offboarding and app deprovisioning aren't wired together.
Worth being honest with stakeholders about one thing in particular: screen-capture blocking and DLP controls reduce insider exfiltration risk, they don't eliminate it. A second phone photographing the first phone's screen defeats almost every app-level control you can configure. That's a residual risk to name explicitly, not a gap to quietly hope nobody notices.
Location changes the threat model, not just the time zone
This is the part a purely technical security review tends to miss, because it isn't a configuration setting — it's geography. A global workforce means the same App Protection Policy is being asked to do very different jobs depending on where the phone physically is:
-
Border searches. Some countries can legally compel a device unlock at customs. Organizations with frequent travelers to higher-risk destinations often issue "clean" loaner devices with no instance access rather than let staff carry their primary phone through.
-
Lawful intercept and state surveillance. In certain jurisdictions, mobile carrier traffic itself is a risk surface — which argues for mandatory corporate VPN, or in extreme cases, disabling the app on local carrier networks entirely.
-
Data residency law. A user's country may legally require their data to stay within its borders — a real conflict if the Intune tenant or the ServiceNow instance is hosted elsewhere, and not something a global default policy can resolve on its own.
-
Follow-the-sun response. A stolen-device report filed at 2 a.m. local time is only as good as the security team available to act on it. A single-region SOC quietly turns a one-hour SLA into an eight-hour one, purely based on where the incident happened.
-
Breach-notification clocks aren't global. GDPR's 72 hours is well known; plenty of other jurisdictions run on entirely different timelines. The escalation matrix needs a regional reference, not one number that gets applied everywhere by habit.
None of this means a different app for every country. It means the policy defaults — MDM vs. BYOD, VPN requirement, wipe SLA — should be reviewable per region, with Legal and Compliance in the room, rather than inherited silently from whatever the pilot group happened to use.
Not every ticket is an incident
Once the threat model is understood, the operational question follows naturally: what happens when something actually goes wrong, and who picks up the ticket? A surprising number of Now Mobile rollouts route everything — a lost device, a sync bug, a new-hire access request — into the same generic support queue. That's how urgent security events end up waiting behind password resets.
A cleaner model routes by scenario type, not by "it's a mobile ticket":
-
A lost device, suspected compromise, or jailbreak alert becomes a Security Incident, handled through
Security Incident Responsewith restricted visibility — kept off the general Incident dashboard entirely. -
A sync failure or login bug stays a routine Incident, triaged by the regular service desk.
-
New access or a role change is a Service Catalog Request, ideally automated end to end rather than manually worked.
-
Offboarding is a Request Task triggered directly off the HR/identity event — not something that waits for a manager to remember to submit a ticket.
-
A recurring vendor defect becomes a Problem, linked to the Incidents it spawned, so the root cause gets tracked instead of re-litigated on every occurrence.
Users shouldn't need to know this taxonomy to report a problem — one intake point with a short triage question set can classify and route behind the scenes. But it should be possible for a routine-looking Incident to escalate into a Security Incident mid-investigation without losing its history, because "app won't sync" and "device is compromised" sometimes turn out to be the same ticket wearing different clothes.
The takeaway
None of this is an argument against enabling Now Mobile — the productivity case for it is obvious. It's an argument for treating it as its own access channel with its own governance, rather than an extension of the web instance that inherits its security posture by default. The teams that get this right tend to do four things before a single development story ships to production: pick the deployment model deliberately per user group, name the full threat surface rather than just theft, build regional variation into the policy instead of assuming one size fits every country, and route incidents by scenario rather than by device type. Everything else in the framework follows from getting those four decisions right early.