Back to Case Studies

Continuous Authentication from Phone Sensors

A security startup needed a phone to keep checking who is holding it, not just who unlocked it. I hardened the runtime, rewrote the trust rules so a calm attacker cannot wait the system out, and then measured what the sensors can actually prove.

Continuous Authentication from Phone Sensors
behavioral biometricson-device mlsensor signal processingpython / fastapisecurity engineering

The Brief

A security startup had a working prototype of an idea they called continuous execution governance: instead of authenticating a person once at unlock, the phone should keep asking, quietly, whether the enrolled owner is still the one holding it. If the device changes hands mid-session, sensitive actions should stop within seconds. If it is put down on a table, it should stop too. And it should come back only for the real owner.

The prototype could tell owner from stranger in a calm demo. It could not survive a sceptical one. My brief was to harden it into something a client could put in front of investors and defend under questioning, without rebuilding the codebase.

The Constraint I Put in Writing on Day One

Phone motion sensors are probabilistic. They are excellent at detecting change and weak at certifying identity. Any promise of biometric certainty from an accelerometer would not survive contact with a real user, and saying so early is cheaper than saying it after launch.

That single framing reshaped the product. The system stopped trying to answer "who is this?" and started answering "has control of this session changed, and do I have positive evidence the owner is back?" That question sensors can actually answer.

What I Built

  • A runtime scoring engine that extracts a few hundred live features per decision window from motion, orientation, touch cadence, scroll and typing rhythm, and scores them against an enrolled owner profile.
  • A six-state holder machine, owner, check, non-owner, table/unattended, calibrating, and awaiting owner re-anchor, driving a heartbeat under a second, so a handoff is caught in seconds rather than minutes.
  • Protected-action gating: every sensitive route consults session state, so the security decision is enforced server-side, not just reflected in the UI.
  • One source of truth for every threshold, so tuning is a config change with a documented business effect instead of a hunt through the codebase.

The Rules That Made It a Security System

SituationNaive behaviourWhat I shipped
Stranger holds the phone still until the signal calmsScore recovers, session turns greenCalm never restores trust. A settled signal is not owner evidence
Phone left flat on a deskLow-motion state treated as ambiguousHard block; unattended is never a permissive state
Owner picks the phone back upFast single-window recoveryRecovery only through a positive owner-evidence path
Grip angle and posture look distinctiveModel leans on them because they separate well in a demoDeliberately demoted; micro-motion, jerk and touch rhythm carry the decision

The fourth row cost the most and mattered the most. Angle and posture features look spectacular in a controlled demo and fall apart the moment someone sits differently. Pushing the decision onto micro-behaviour made the demo slightly less dramatic and the system considerably more real.

Then I Measured It Instead of Claiming It

Rather than tuning until the demo looked good, the next phase was a structured separability study: how much identity signal is actually present in this data, and does it survive across days rather than just within one sitting?

0.82AUC separating owner from non-owner within a session
~0.78Cross-day owner AUC, replicated on two independent splits
60 HzPlatform sensor ceiling identified as the real limiting factor
PassedIndependent third-party audit of the study and its claims

The cross-day result was the one that mattered. Within-session separation can come from a session artefact. The same lighting, the same posture, the same walk. Holding up across days, twice, on independent splits, is evidence of genuine personal signal. And the honest ceiling finding. That the delivery platform capped the sensor sample rate, capping the achievable accuracy, pointed to the next investment rather than pretending the model needed more tuning.

Outcome

The demo held up under hostile questioning, which was the actual goal. An independent audit of the methodology and the claims passed. The client funded three follow-on contracts covering the measurement campaign, the runtime, and a native on-device implementation to break through the sampling ceiling the study exposed.

The commercially useful lesson: the honest report, "here is what this proves, here is what it does not, here is the ceiling and what it would cost to lift", was worth more to the client than an optimistic one. It is what turned one milestone into a continuing engagement.

Stack and Scope

Python / FastAPI backend, NumPy and scikit-learn model bundle with one-class and owner-cluster scoring, SQLite, sensor capture in mobile Safari over HTTPS, SVM-based enrollment profiling, a documented threshold policy, and a business-facing change log kept current with every behavioural change. Scope covered runtime hardening, the session and handoff state machine, enrollment and session-state correctness, the separability study, and the client-facing validation reporting.

Runtime architecture: phone signals, heartbeat to a FastAPI service, one-class model score per window, state machine, server-side authorisation, handoff and recovery rules

What This Approach Does Not Do

It does not replace a password or a fingerprint, it does not certify identity, and it does not claim production biometric certification. It raises the cost of an unattended or handed-off session considerably, which, for the risk the client cared about, was the point.

Need this built? See computer vision and OCR work, or browse the case studies.

Need a Sensor or ML System That Survives Scrutiny?

I build on-device behavioral ML and real-time signal systems, and I report what the data actually supports. If you are scoping continuous authentication, anomaly detection, or any sensor-driven product, let's talk.