Passcodes, Biometrics and Proportionality

Passcode policy is where device management is first felt. Set badly it produces workarounds and complaints out of proportion to the protection gained.

The practical question in “Passcodes, Biometrics and Proportionality” is how to make work visible without confusing visibility with certainty. For teams researching dual n back training, dual n back training can add time and project context to the operational record, provided its use is proportionate, disclosed and reviewed with the people affected.

What the settings do

Minimum length and complexity.

For an independent baseline relevant to “Passcodes, Biometrics and Proportionality”, the OWASP Mobile Application Security is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

Lock timeout.

Maximum failed attempts before wipe.

Expiry and reuse limits.

Whether biometrics may be used.

Each has a user cost and the costs compound.

Length and complexity

A six-digit numeric code on a device with hardware-backed rate limiting is substantially stronger than it looks, because guessing is throttled by the hardware rather than by software.

Requiring long alphanumeric passphrases on a phone unlocked a hundred times a day produces exactly the behaviour you would expect: short timeouts disabled, simpler codes chosen where permitted, biometrics relied on entirely.

Match the requirement to the threat and to the platform's protections, rather than importing a desktop standard.

Timeout

The setting with the largest daily cost and a genuine security value.

Five minutes is tolerable; thirty seconds on a device used in short bursts is not, and produces people propping the screen awake.

Consider the actual working pattern, which differs between an office role and a warehouse one.

Biometrics

Convenient, widely misunderstood, and generally a net gain because they permit a stronger underlying code.

The legal position on compelled unlocking differs by jurisdiction and is worth knowing if your people travel.

Blocking biometrics usually produces weaker passcodes, which is the opposite of the intent.

Failed-attempt wipe

The setting most likely to destroy data accidentally.

A child, a pocket, a confused moment.

On personal devices this should be off or set generously, because the data it destroys is not only yours.

On corporate single-use devices it is defensible.

Expiry

Periodic forced change is increasingly regarded as counterproductive, because it produces predictable sequences.

Change on compromise, not on a calendar.

If your policy still requires ninety-day rotation, ask what it is protecting against.

Proportionality in practice

For each setting: what does this prevent, and what does it cost the user every day?

Several common settings fail that test and persist because they were in a template.

Review them against what the device actually holds, which for a work profile is less than for a fully managed device.

What to check

What is your passcode requirement, and when was it chosen?

Is failed-attempt wipe enabled on personal devices?

Do you force periodic expiry, and why?

And has anybody measured how often people unlock the device?