Skip to content
The Cyber Security Place

Defence

Mobile security in 2026: the endpoint you do not own

For a decade the worry was company data walking out in somebody's pocket. The pocket now holds the key to everything else, and it belongs to the person carrying it.

Last reviewed August 25, 2026

A professionally managed handset meets around 360 security events a year, of which roughly 120 need an administrator to look and about 10 are confirmed serious attacks — several a day across an ordinary fleet. Lures arriving by text or voice are clicked at rates about 40% higher than the same material by email, and some 63% of users receive at least one text lure inside 90 days. Spyware detections rose about 51% in a year as surveillance-grade capability reached ordinary criminal tooling. The platform is strong; what is weak is that the recovery channel for work sign-in, banking and personal email all converge on a device the employer does not own and a number the carrier controls. Management software covers the work profile and not the personal half, where the lures land — so the console can read green throughout a compromise, accurately.

How much actually happens to one phone?

Most people carry a number for this and it is wrong by a factor rather than a margin. Put yours in first, because the size of the gap is the finding.

Worked exampleGuess first, then look

  1. Security events a professional smartphone meets in a yearEverything the tooling notices: lures, risky networks, dubious permissions, blocked connections.

    360events, measured

    Up from about 342 two years earlier. Most are noise, and the number is why nobody reads the log.

  2. Of those, how many need somebody to look at themModerate findings that an administrator is expected to triage rather than dismiss.

    120a year, measured

    One every three days, per device, across the whole fleet. That is the workload nobody staffed for.

  3. And how many are confirmed serious attacksAttacks judged severe enough to require blocking immediately, per device.

    10a year, measured

    Ten per device per year is not a rare event. On a fleet of two hundred it is roughly five a day.

Figures published for professionally managed handsets and given as orders of magnitude rather than as precise counts. The distribution matters more than any single number: the vast bulk is noise, a substantial middle requires judgement nobody has budgeted for, and a small tail is real. Underestimating the middle is what leaves that tier unstaffed on most fleets.

The tier that matters is the middle one. Ten confirmed attacks per device per year gets attention, because a confirmed attack generates a ticket and somebody senior asks about it. The hundred-odd findings that sit below that threshold are the ones requiring a judgement — is this application's permission set reasonable, does this network warrant concern, is this profile supposed to be installed — and on most fleets nobody has been given the hours to make those judgements.

That is a staffing observation rather than a technical one, and it explains a pattern visible in incident write-ups. The finding that preceded the compromise was usually present in the console for weeks. It was not missed through incompetence; it was one of a hundred and twenty, in a queue owned by somebody whose actual job was mobile provisioning.

The device everything else recovers through

Draw the dependencies and the picture is not a list of risks. It is one object with six things hanging off it.

one phoneWork sign-insecond factor, or the passkey itselfBank accountapproval prompt, one-time codePersonal emailwhich recovers most of the restPassword managerunlocked by the device biometricGovernment identitywallet credential, tax portalMessagingthe number is the account

Every arrow points outwards, and that is the whole diagram. Each of those six can be reached or restored through the handset; none of the six can be restored without it. Nobody designed that concentration. It arrived one sensible decision at a time, each of which improved security in isolation: put the second factor on something the person always carries, move approvals into an application instead of a text, let the biometric unlock the vault.

The result is a single point of failure that no risk register lists, because risk registers are organised by system and this is a property of the arrangement between systems. It is also a point of failure the organisation does not administer, does not patch, cannot inspect and did not buy.

Which reframes what the useful question is. Not how do we secure the phone, which is largely the manufacturer's work and is going well. It is what still functions when this device is gone or in somebody else's hands, and for most organisations the honest answer today is very little.

Why do text lures work better than email?

Measured against the same material sent by email, lures arriving as messages or calls are clicked at rates roughly forty per cent higher. Several properties compound, and none of them is about the recipient being careless.

There is nothing to inspect. Two decades of advice rest on examining a sender address and hovering over a link. A message has a number rather than a domain, and the screen offers no way to see where anything leads before it opens.

The channel carries an assumption of legitimacy. Texts are what the bank, the courier and the doctor use. It is a channel people associate with short factual notices rather than with correspondence, and shortness reads as authenticity.

The defensive layer is missing. Corporate mail passes through filtering, rewriting, sandboxing and banners built up over twenty years. A text arrives from the carrier straight onto the screen with none of that between.

The context is worse. Messages are read while walking, queuing, half attending to something else, on a screen that shows a fragment. Every condition that aids judgement is absent.

With roughly sixty-three per cent of users receiving at least one such lure inside ninety days, this is the most widely experienced attack described anywhere on this site, and the one with the least infrastructure behind stopping it.

A decade spent guarding the other direction

359 reports were filed here, and this section peaks earlier than any other in the archive — in 2015, when the argument it was having was a different argument.

Reports in this section, by year
2015201620172018201920202021
69508557332524

The subject of those years is containment, and the direction of concern runs outwards. How does a spreadsheet stop leaving the building on a handset nobody controls. How is a work partition separated from a personal one. What happens when somebody resigns and the device goes with them. Management platforms, containers, remote wipe, encryption at rest.

Enterprise Mobility: Security is essential, August 13, 2014, sits squarely in that register. The questions it raises were answered, largely successfully, and the platforms it describes are still in service doing what they were built to do.

What nobody was asking then is what this page is about. The handset of 2015 held copies of things. The handset of 2026 holds the means of obtaining things, which is a different asset entirely and inverts which way the risk runs. Remote wipe protects the copies. It does nothing about the fact that the missing device was the recovery route for six other services.

Android carries the technical coverage across the decade —106 of these reports mention it — largely as a story about the difficulty of getting updates onto a fragmented population of devices. That specific problem improved considerably. The framing it belonged to did not survive.

Surveillance tools reaching ordinary criminals

Detections of spying software rose by around half in a year, and the notable part is not the growth rate but who is now holding the capability.

For most of the past decade, tooling able to read messages before encryption, activate a microphone or extract a photo library sat with a small number of commercial suppliers selling to governments, at prices that limited its use to a handful of targets per operation. The techniques were remarkable and the population exposed to them was tiny.

That boundary is dissolving. Capabilities characteristic of those suites are appearing inside ordinary criminal tooling, offered on subscription in the same marketplaces as everything else. The engineering is not being reinvented; it is being packaged, and packaging is what turns a technique used against a hundred people into a technique used against a hundred thousand.

For an ordinary organisation the practical consequence is narrow but real. Nobody should plan around a national adversary, and the class of tool that reads a messaging application before encryption is now cheap enough to be used against a finance director in a mid-sized firm — which changes who should be considered a plausible target, without changing much about what to do. The controls remain prompt updates, restricted permissions and the assumption that a compromised handset yields whatever it can reach.

There is one detection signal worth knowing about, because it is the only practical one available to somebody without a forensics budget. Both major platforms now ship a hardened mode that disables the message-parsing and rendering features these tools rely on, at a cost in convenience most people would not accept permanently. Turning it on for the handful of roles that plausibly attract this attention — the finance director, the head of legal, anybody named in a filing — is a setting rather than a project.

Is the phone more or less secure than a laptop?

The platform is markedly stronger and the situation around it is markedly weaker, and conflating those two is the source of most bad decisions in this area.

On the platform, the mobile operating systems won an argument the desktop is still having. Applications are isolated from one another by default rather than by exception. The system verifies itself at boot. Updates install because they install, not because somebody scheduled a maintenance window. Permissions are granted per capability, revocably, with the user asked at the moment of use. Any desktop estate with those properties would be considered exemplary.

The situation is another matter. The device joins networks nobody vetted. It receives messages through a channel with no filtering. It runs personal applications chosen by its owner, several of which embed third-party components that collect more than the owner would guess. And it is administered — to whatever extent it is administered at all — by somebody whose authority stops at the work partition.

So the honest comparison is that the handset is a better-built machine in a worse neighbourhood. Which suggests where effort belongs: not in hardening a platform that is already hardened, but in the channels reaching it and in what its compromise would yield.

What does management software actually control?

Less than the people who bought it believe, and that gap between belief and reality is worth closing before anything else on this page.

On a personally owned handset enrolled in the usual way, the platform genuinely controls a work profile: the applications inside it, the data they hold, the policy applied to them, and the ability to remove that entire partition remotely. This is a good design and it does what it claims.

What sits outside that boundary is everything else. Personal applications and their permissions. Messages arriving in the personal inbox — which is where the lures arrive. Personal browsing. The photo library. Whether a profile has been installed by somebody else. The operating system's patch level, in many configurations, is visible but not enforceable.

The mismatch this creates is specific and common. A security team reports that the fleet is managed, meaning enrolled, and a board hears that the fleet is controlled. The compromise that eventually occurs arrives entirely through the unmanaged half, and the console shows a green tick throughout, accurately, because the work profile was never the problem.

Saying this plainly is not an argument against the platforms, which are worth having. It is an argument for describing them precisely, so that the controls addressing the other half get designed rather than assumed.

The number a third party controls

Beneath every arrangement described above sits an identifier that neither the organisation nor the individual actually owns.

A telephone number is issued by a carrier and can be moved by that carrier to a different device, on the strength of a conversation with somebody in a shop or a call centre who is measured on customer satisfaction rather than on refusals. Every code sent to it follows. The organisation protecting an account with those codes has no visibility into the transfer, no ability to prevent it and no notification when it occurs.

The archive noticed the mechanism early enough — the subject appears 18 times across the decade — but as a curiosity affecting cryptocurrency holders rather than as a structural weakness under mainstream authentication. What changed is not the technique but how much now hangs from the identifier.

10 Essential Elements for a Secure Enterprise Mobility Strategy – 10 Essential Elements for a Secure Enterprise Mobility Strategy - ran in April 13, 2015, when the exposure looked like an edge case. The same transfer today reaches work sign-in, banking approval and the personal mailbox that recovers everything else.

Two responses exist and both are cheap. A port-out lock or transfer PIN with the carrier makes the conversation harder to have, and every major operator offers one that almost nobody has enabled. Moving authentication to a passkey removes the code entirely, so a transferred number delivers nothing worth having.

Should personal handsets hold work access at all?

Asked as a policy question this produces a paragraph everybody ignores. Asked as an economic one it produces a decision, so it is worth asking that way.

The reason personal devices carry work access is not laxity. The second factor has to live on something the person always has, issuing and maintaining a handset for every employee is expensive, and the people who most need remote access are the ones least willing to carry two devices. Those pressures produced the current arrangement in almost every organisation, including the ones whose written policy forbids it.

Three positions are actually available. Issue corporate handsets to everyone, which is clean, costly, and produces a second phone that stays in a drawer while people use their own anyway. Permit personal devices with enrolment, which is what most have, and which controls the work half while leaving the exposure in the personal half. Or permit personal devices with no enrolment at all and put the security entirely into the credential, so that what the handset holds is a passkey bound to the hardware and nothing else worth taking.

That third option is newer than the debate around it and deserves more attention than it gets. If work sign-in is a passkey, work mail is reached through a browser session that expires, and no document is stored locally, then the handset holds very little and the question of who administers it matters correspondingly less. It trades management reach for a smaller prize, which is the same trade the rest of this site keeps recommending in other contexts.

What does not work is the arrangement most organisations are in without having chosen it: personal devices, partial enrolment, a written policy nobody follows, and an assumption on the security team's part that the console reflects the fleet. That is not a middle position between the three above. It is the absence of a decision, and it fails in the specific way described earlier — accurately green, on the half that was never the problem.

Designing so that losing it is survivable

Since the concentration cannot realistically be undone, the work is making the failure recoverable. Four measures, in order of what they return.

Write and test the recovery path. Somebody loses the handset on a Friday evening. Which route restores their work access, who authorises it, and does any step in that route require the missing device? Almost every organisation discovers during a real incident that it does. Testing this once costs an afternoon.

Enrol a second factor that is not the phone. A hardware key in a drawer, one per person, unused for years and decisive on the day it is needed. This is the single measure that breaks the concentration in the diagram above.

Lock the number with the carrier. Free, immediate, and it closes the transfer route that everything else depends on.

Treat text and voice as an unfiltered channel, out loud. Staff have twenty years of instruction about email and almost none about the channel that is now working better. Naming the specific requests that require a second channel — a bank detail change, an urgent transfer, a code read aloud — is a rule people can follow while distracted.

Where to start on a Monday

Three exercises, none of which needs a purchase, and each of which usually produces an uncomfortable answer within an hour.

List what recovers through a phone. Take the ten accounts that matter most and write down, for each, what happens if the handset is unavailable. The concentration will be worse than expected, and the list is the argument for everything else.

Ask who reads the middle tier. Open the management console and look at the findings below the severe threshold. Ask, by name, who triages those. If the answer is nobody, that is not a failure to correct so much as a decision to make deliberately.

Run the lost-phone drill. Pick somebody, pretend the device is gone, and time how long until they have work access again. Do it in the afternoon rather than the morning, because the failure mode is usually that the person who authorises the reset has gone home.

After those three the harder work is prioritisable: issuing second factors that are not handsets, moving sign-in to passkeys, and staffing the tier that nobody reads. An organisation that has done the first three knows what a lost phone costs it in hours, which is a question almost nobody can currently answer.

Common questions

How much actually happens to one work phone in a year?

Reported figures for professionally managed handsets put it near 360 security events annually, of which roughly 120 are judged to need an administrator's attention and about 10 are confirmed serious attacks. Ten per device per year across a fleet is several a day.

Why do text and voice lures work better than email?

Measured click rates for messaging and voice run around 40% higher than for email in the same simulations. The message arrives with no sender domain to inspect, no hover preview, no banner, on a small screen, usually while the recipient is doing something else.

How common are text-message lures?

Roughly 63% of mobile users report receiving at least one in a ninety-day window. It is the most widely experienced attack in this entire archive and the one with the least tooling behind it.

Is a phone more or less secure than a laptop?

The platform is considerably stronger: applications are isolated from one another, the operating system is signed and verified at boot, and updates install without anybody deciding. What is weaker is everything around it — the network it joins, the messages it receives, and the fact that nobody manages the personal half.

What does device management software actually control?

On a personal handset, considerably less than most people assume: typically the work profile, its applications and its data, with the ability to wipe that portion. It does not see personal applications, personal messages or personal browsing, which is where most of the exposure sits.

Has commercial spyware become a mainstream problem?

It is heading that way. Spyware detections rose by around 51% in a year, and capability once confined to state-grade suppliers is arriving in ordinary criminal tooling through subscription services. The interesting change is who can buy it rather than what it does.

Should personal phones hold work access at all?

Most organisations cannot avoid it, because the second factor has to live somewhere and issuing hardware to everybody is expensive. The workable position is to accept the arrangement and reduce what a compromised handset yields, rather than to write a policy that is quietly ignored.

What is the risk from the phone number itself?

It is an identity anchor that a third party controls. Anybody who persuades the carrier to move the number receives the codes, and the organisation whose account is protected by those codes has no visibility into that transaction and no say in it.

Do passkeys on a phone improve or worsen this?

They improve it substantially, because the credential cannot be replayed against a lookalike site and never leaves the device. They also concentrate more into the handset, which makes recovery design the part that must be got right.

What should happen when somebody loses their phone?

There should be a written path that does not depend on the lost device, tested at least once. Most organisations discover during the incident that every route to restoring access runs through the thing that is missing.

Are official app stores safe?

Considerably safer than the alternative, and not a guarantee. Malicious applications do reach official stores, usually by behaving normally until after review. The larger everyday exposure is legitimate applications with excessive permissions and embedded third-party components collecting more than anybody intended.

What is the single most useful control?

A carrier lock or port-out PIN on the number, which costs nothing and closes the transfer route. After that, moving work sign-in to a passkey, which removes the code that a transferred number would have delivered.

Endpoint and mobile coverage

359 reports, newest first. Most cited sources: helpnetsecurity.com (52), infosecurity-magazine.com (27), itproportal.com (20), securityaffairs.co (12), csoonline.com (11), zdnet.com (9).