Continuous authentication versus gating the actions that matter
Both promise that the person acting is the person authorised. They differ in what they collect, what they produce, and whether the answer is a score someone has to interpret.
Which approach actually stops the loss?
Gating, on the small set of actions that cause it. Continuous authentication produces a confidence score that has to be thresholded, and every threshold is either too loud to act on or too quiet to catch a patient operative. Gating produces a signature or nothing.
- Continuous authentication produces a confidence score from observation; per-action gating produces a binary result from a challenge.
- The score must be thresholded, and any threshold trades false positives against missed detections at a very low base rate.
- Per-action gating collects nothing and covers only the actions it is applied to — which is its main limitation and also why it is deployable.
Part of Remote workforce identity
Side by side
| Property | Continuous authentication | Per-action gating |
|---|---|---|
| Data collected | Behavioural telemetry, continuously | Nothing between actions |
| Output | A confidence score | Valid or invalid |
| Requires interpretation | Yes — a threshold and triage | No |
| Coverage | All activity | Only gated actions |
| User experience | Invisible until it flags you | A gesture at defined points |
| Failure mode | False positives at scale | An attacker uses an ungated path |
| Privacy and legal posture | Complex in many jurisdictions | Straightforward |
| Evidence produced | A score and a log | A verifiable signature |
Two rows determine most of the decision: what is collected, and whether the output requires a human to interpret it.
The threshold problem
A continuous system outputs a number and someone must decide what number triggers an action. That decision cannot be avoided and has no good answer at a low base rate.
Threshold too sensitive:
hundreds of employees flagged for typing differently
→ alerts ignored, control becomes decorative
Threshold too permissive:
a competent impostor stays inside the band
→ nothing is detected
Between:
both problems, proportionallyThere is no setting that produces high precision when genuine impostors are a handful in ten thousand. That is arithmetic rather than a product limitation.
The honest weakness of gating
Coverage. It protects exactly the actions it is applied to, and an attacker who finds an ungated path takes it.
This is a real limitation and it is manageable in a way the threshold problem is not, because it is an enumeration exercise. The set of irreversible actions in a system is finite and findable; the set of behaviours that indicate an impostor is not.
- Money movement and changes to payment destinations
- Permission and role changes
- Bulk data access and export
- Credential enrolment and recovery
- Destructive operations and configuration of logging or retention
In most enterprise systems that is ten to thirty endpoints, discoverable in a day.
What the step-away case reveals
A common argument for continuous authentication: it notices when a user walks away and someone else sits down.
In practice it notices this by detecting a behavioural change, which means it has the same precision problem — and a user who steps away and returns produces the same signal as a substitution.
Per-action gating handles the scenario differently and more definitively. The person who sits down can browse. They cannot move money, because that requires a gesture on a credential they do not have.
Where continuous signals do belong
As an input to when a challenge is required, rather than as a detector.
# The productive combination
risk_signal = behavioural_model(session) # probabilistic
if action in GATED_SET:
require_signature() # always
elif risk_signal > elevated:
require_signature() # sometimes
else:
proceed()
# The signal adjusts when proof is demanded.
# It never accuses anyone, and it never decides alone.In this arrangement a false positive costs the user a few seconds rather than an investigation, which is the right cost for a signal of that precision.
Choosing between them
| If your priority is | Choose |
|---|---|
| Preventing high-consequence unauthorised actions | Per-action gating |
| Evidence for an auditor or a claim | Per-action gating — it produces a verifiable artefact |
| Operating under strict employee monitoring law | Per-action gating — it collects nothing |
| Broad visibility into anomalous activity | Continuous signals, as input rather than verdict |
| Both | Gating on the enumerated set, signals to trigger additional challenges |
The practical recommendation is the last row, with the order mattering: enumerate and gate first, then add signals. Deploying signals first produces alerts nobody can act on, and organisations that do it in that order tend to abandon both.
A worked comparison
Take one quarter in a 4,000-person organisation with roughly 90 payment-release, code-signing and privileged-access actions a day.
| Continuous | Gating | |
|---|---|---|
| Events generated | ~11,000 anomaly alerts | ~8,100 signature prompts |
| Investigated by a human | A sampled fraction | None — the user signs or does not |
| Blocked at the moment of effect | Nothing; alerts are after the fact | Every unsigned action |
| Evidence at dispute | A score and a model version | A signature over the rendered effect |
| False positives on a wrist injury | Sustained, for weeks | Zero |
Those counts are illustrative, but the shape is not: one approach generates work proportional to headcount, the other generates work proportional to consequential actions — a much smaller number that does not grow when someone changes keyboards.
Objections and honest limits
“Gating misses everything between the gates.” It does, and this is the real weakness. The answer is not to lower the bar but to choose gates that sit where loss is realised — payment release, privileged escalation, bulk export, code signing.
“Continuous signals must be worth something.” They are, for routing and for investigation after the fact. They are a poor basis for blocking, because blocking on a probability means blocking tired people.
Choosing gates that matter
- List the actions where loss is actually realised. Usually far fewer than expected.
- Rank them by irreversibility. Wire release and code signing before report viewing.
- Gate the top of that list with a signature. Over the rendered effect, not the request.
- Leave continuous signals as routing input. Useful for investigation, poor for blocking.
- Measure prompt volume per person per week. If it exceeds a handful, the gates are wrong.
Terms used here
- Continuous authentication
- Ongoing behavioural assessment producing a confidence score rather than a discrete decision.
- Per-action gating
- Requiring a fresh cryptographic assertion at a specific, consequential action.
- Threshold problem
- The impossibility of setting a score cut-off that is both actionable and sensitive.
Frequently asked questions
Why is thresholding unavoidable for continuous authentication? It outputs a score, so someone must set a trigger point. At a very low base rate no setting produces high precision.
What is per-action gating's real weakness? Coverage — it protects only the actions it is applied to. That is manageable because the set of irreversible actions is finite and enumerable.
What about someone sitting down at an unattended machine? They can browse. They cannot move money, because that requires a gesture on a credential they do not have.
Should behavioural signals be used at all? Yes, as an input deciding when to demand proof. A false positive then costs seconds rather than an investigation.
Is continuous authentication useless? No. It is useful for routing and post-hoc investigation. It is a poor basis for blocking, because the score has to be thresholded and every threshold is wrong somewhere.
How many gates is the right number? Few enough that a typical person meets one a handful of times a week. More than that and the gates are on the wrong actions.
Does gating leave gaps? Yes, by design. Everything between gates is ungated, which is why gate placement is the whole exercise.
Where this fits in Manav
Manav is a gating primitive: a hardware signature over the rendered effect at the moment it happens, verifiable offline afterwards.