Device Intelligence Is No Longer a Proxy for Identity Trust

Guest article by Henry Patishman, Regula

The UK government has committed to legislation requiring major technology platforms to build child-safety protections into devices. The proposal follows work with Apple and Google on controls intended to prevent children from taking, viewing, or sharing nude images, including operating-system-level age assurance.

Device-level protection can apply across apps, but moving enforcement to the phone does not resolve a basic identity question: who is using it? A phone may be shared within a family or registered to an adult and used by a child. That does not weaken the case for device-level controls. It shows why those controls still need reliable evidence about the person currently using the device.

The same distinction matters far beyond age assurance. Device intelligence can show that an environment looks familiar. On its own, it cannot establish that the expected person is present now.

Here is why.

What Device Intelligence Cannot Prove

The most obvious limitation is that devices are not always personal. They may be shared within a household or workplace, and NIST’s authentication guidance recognizes that more than one person may legitimately use the same device.

Behavioral biometrics may reveal a change in how a familiar device is being used, but they remain risk signals rather than definitive proof of identity. Normal changes in how someone holds or uses a phone may produce false positives, and some behavioral patterns can be imitated.

Device fingerprints have similar limits. Research presented at USENIX Security 2022 and ICDCS 2024 shows that certain browser and canvas fingerprinting attributes can be collected and spoofed under specific conditions. A match may support continuity, but it cannot guarantee continuity of human control.

Recent Regula research reflects this hierarchy of trust. Only 5 percent of respondents selected device and environmental signals as the identity evidence they trusted most, compared with 37 percent for biometrics and 27 percent for chip-enabled documents. This does not make device intelligence unimportant, but it suggests that few organizations see it as their strongest form of identity evidence.

How Identity Drift Changes the Role of Device Trust

I use the term “identity drift” for the gap that opens when the identity associated with a familiar device remains the same, but the person or process controlling the interaction has changed.

There are several ways this can happen.

An attacker may exploit a vulnerability remotely. Google Project Zero’s research into a Pixel exploit chain shows the technical possibility of compromising a device with little or no action from its owner.

Another route is malware disguised as a legitimate application. The Brokewell banking malware, for example, has used accessibility logging, screen streaming, and remote-control capabilities to monitor and operate infected devices.

AI agents add an emerging variant. Research into prompt-injection attacks against agents shows how malicious instructions in external content may cause an agent to misuse the tools or permissions available to it. This risk will become more relevant as agents gain greater access to local systems.

These scenarios are not equally common, but they expose the same weakness. A risk engine may see the expected device, in the expected location, producing the expected signals, even though the interaction is no longer under the expected user’s control.

The device may be genuine while the actor behind the interaction is not. At high-risk moments, the relevant question is whether there is fresh, reliable evidence that the expected person is present now, and whether that evidence was captured live rather than replayed or injected.

Verify the Actor, Not Just the Device

At high-risk moments, the appropriate check depends on what is uncertain: the person’s identity, their live presence, or the integrity of the captured evidence.

These checks are not interchangeable. Document verification assesses the identity evidence, face matching connects it to the person presenting it, and liveness helps establish that a real person is present during the current interaction.

• Live document and biometric capture. During identity proofing or risk-triggered reverification, live capture can provide fresh evidence that the expected person is present. For remote proofing with physical documents, NIST SP 800-63A-4 calls for live capture and document-presence checks. Document validation, face matching, and liveness provide different parts of that evidence and should be evaluated together.
• Fresh biometric evidence. A new face capture with liveness provides more relevant evidence than a biometric or device decision inherited from an earlier session. This is particularly important when familiarity with the device would otherwise reduce or bypass additional verification.
• Capture and application integrity checks. Risk assessment should look for signs that the identity evidence has been injected or manipulated, including virtual cameras, emulators, rooted or jailbroken environments, overlays, unusual accessibility activity, and remote-control tools.
• Correlate the evidence. Device familiarity should be weighed alongside document, biometric, and capture-integrity signals. It may lower the risk associated with an interaction, but it should not override contradictory evidence from the current session.

The aim is not to discard device intelligence, but to keep it in its proper role: context that can trigger or support identity verification, not evidence that replaces it.

Preserve the Evidence Behind the Identity Decision

When a high-risk identity decision is challenged, the organization should be able to reconstruct what the system knew at the time, not merely retrieve its final score.

For identity proofing, NIST SP 800-63A-4 requires credential service providers to maintain records of completed proofing steps. This applies specifically to identity-proofing records, not automatically to every subsequent transaction.

For higher-risk identity decisions, an audit trail should show what evidence was captured, which validation and verification checks were performed, which device and capture-integrity signals were available, which policy or model version was applied, and why the decision was approved, rejected, or escalated. These records cannot identify with certainty who controlled the device, but they can reveal where the system relied too heavily on device familiarity or failed to obtain fresh identity evidence.

What to Change in Your Identity Verification Flow

Start with the moments when a mistaken decision would cause the most harm: account recovery, changes to payment details, high-value transfers, or delegation of authority.

For each action, determine what identity evidence needs to be refreshed and whether capture or device-integrity checks should be strengthened. Then identify where device familiarity currently reduces or bypasses verification, and decide whether that level of trust is still justified.

Device intelligence still provides context, flags anomalies, and supports risk decisions. A familiar device should influence the risk assessment, not settle the identity question. It may show continuity of the environment; on its own, it cannot show that the expected person is present now.