Behind a setting that looks trivial — “switch the screen off after a minute” — there is a mechanism with more parts than you would imagine. Understanding it serves two purposes: configuring it correctly and understanding why it sometimes does not do what you expect.
It expands on the recommendation screen lock timeout.
What “inactivity” means to a device
The starting point is less obvious than expected: the system does not know whether you are there. It only knows whether it is receiving events.
A timer starts at zero and restarts every time an activity signal arrives: a mouse movement, a key pressed, a touch on the screen. When the timer reaches the set threshold without being reset, the switch-off triggers.
That explains something that confuses many people: sitting and reading in front of the screen counts as inactivity. The system does not see you reading — it receives zero events, and concludes you are not there.
Some recent devices add presence detection through the front camera, which keeps the screen on as long as it sees you. It is convenient, but it is worth knowing what it involves: a camera analysing the frame continuously. On well-designed systems the processing happens entirely on the device and no image is saved or transmitted — it is still worth checking that in the settings before turning it on.
The two timers that get confused
It is the most important distinction in this whole post, and it is why many configurations do not work.
| Timer 1 — Switch-off | Timer 2 — Lock | |
|---|---|---|
| What it does | Switches off the display | Closes the session |
| Why it exists | Saving power | Security |
| Where it sits | Power settings | Security settings |
| Effect of shortening it | The battery lasts longer | The device is protected sooner |
| If you configure only this | No protection | Partial protection |
The two timers run in sequence: the second starts when the first ends. If you have switch-off at 2 minutes and lock at 5 minutes after switch-off, the real window is 7 minutes, not 2.
It is the calculation almost nobody does, and it is why many people convinced they have a quick lock actually have a very long window.
What happens at the moment of locking
Locking is not just a screen covering the desktop. It is a precise sequence.
1. The graphical session is isolated. The screen’s content is no longer drawn: what you see is a separate screen, and the windows underneath cannot be reached.
2. Input is redirected. Keyboard and mouse stop talking to the applications and talk only to the lock screen. It is why you cannot type “blind” into an application behind the lock.
3. Some secrets are removed from memory. It is the least visible part and the most relevant. On modern systems, locking causes certain encryption keys to be cleared from active memory.
The third point is what connects this unit to data encryption: a device that is on and unlocked has its keys in memory, so the data is in the clear. Encryption protects a device that is off or locked, not one that is open. It is the technical reason why locking the screen is not an accessory to encryption: it is its condition.
Locking, sleep, shutdown: three different things
Confusing them leads to poor choices.
| State | What stays on | What happens to the data | Resuming |
|---|---|---|---|
| Screen off | Everything except the display | Keys in memory, data in the clear | Instant |
| Locked | Everything: the apps keep running | Some keys removed | Instant, with authentication |
| Asleep | Only the memory | Keys in memory (still reachable) | A few seconds |
| Hibernated | Nothing | Memory written to disk, encrypted | Tens of seconds |
| Off | Nothing | Everything encrypted, keys absent | A full startup |
The most important row is “Locked”: the applications keep working, downloads continue, meetings stay active. Locking the screen interrupts nothing — it is the most common objection and it has no basis.
The “Asleep” row deserves a note: sleep is not safer than locking, because the memory stays powered. The advantage is energy, not security.
Why the screen sometimes does not switch off
Applications can ask the system to suspend the timer. It is a legitimate mechanism — it goes by various names depending on the system, but the logic is the same: an application declares “I am doing something the user is watching” and the timer stops.
| Who uses it legitimately | Why |
|---|---|
| Video players | Watching a film generates no input events |
| Presentations | The same reason |
| Satellite navigation | The screen has to stay readable in the car |
| Video calls | You are present but touching nothing |
| Long installations and backups | The process must not be interrupted |
The problem arises when an application keeps it active for no reason: a badly written web page, an app left in the foreground, a process that never released the request.
The symptom is clear: the screen never switches off and the battery drains quickly. On desktop systems there are commands listing which processes are keeping the system awake; on phones the battery section shows which app kept the screen on the longest.
How unlocking works: the methods compared
Locking is only useful if unlocking is quick enough not to push you into turning it off. This is the part where technology made the real difference.
| Method | Speed | Robustness | Note |
|---|---|---|---|
| A long password | Slow | High | Unsustainable dozens of times a day |
| A passcode | Medium | Medium | Depends on the length |
| A pattern | Medium | Low | It leaves visible traces on the glass |
| Fingerprint | Very quick | High | It fails with wet hands |
| Face recognition | Very quick | Variable | It depends a great deal on the implementation |
| A proximity device | Automatic | Medium | It unlocks the computer if your watch or phone is nearby |
The technical point that counts: biometrics do not replace the code, they sit alongside it. The biometric data stays on the device, in an isolated component, and is never transmitted; the code remains as the fallback and is requested after a restart, after a long period of disuse, or after several failed biometric attempts.
It is a deliberate design choice: biometrics are made for frequency, the code for robustness. And it is what makes a thirty-second timeout sustainable.
The last row of the table — proximity unlocking — deserves a caveat: it is convenient but the weakest in this specific scenario, because if you leave your desk without your phone or watch the computer stays unlockable by whoever is there.
Policies managed by organisations
On company devices the timeout is often imposed centrally and cannot be changed. It is not a lack of trust: it follows from the fact that the device holds data not belonging to whoever uses it.
On a personal device also used for work, modern systems separate the two profiles: the rules apply only to the work side. It is useful to know, because it explains why the phone sometimes behaves differently depending on which app you are using.
Why the defaults are so permissive
It is a legitimate question: if a short timeout is so important, why do devices not ship configured that way?
The answer is not negligence. It is the result of design constraints in conflict with each other, and knowing them helps explain why the decision has to be yours.
The first constraint is the first impression. A device just switched on that locks constantly while the person is still learning to use it generates frustration. The initial values are tuned for the learning phase, not for daily use — and nobody goes back to change them afterwards.
The second is support. An aggressive timeout produces support calls: “the computer locks by itself”, “I lose what I am doing”. The second complaint rests on a mistaken idea — locking closes nothing — but the cost of explaining it is real.
The third is the unknown context. Whoever makes the device does not know where it will be used: a tablet in the kitchen, a laptop in an open-plan office, a teenager’s phone. The default is a compromise across every case, so it is optimal for none.
The fourth is historical. Many defaults date from a time when unlocking meant typing a password. In that context a thirty-second timeout really was unsustainable. Biometrics changed the equation, but the values largely stayed where they were.
On devices managed by an organisation the conflict is resolved differently: whoever writes the policy knows the context and can impose a suitable value. On a personal device you play that role — and it is why this setting should be decided, not inherited.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Skills | Telling the two timers apart and working out the real window |
| Awareness | Understanding that on an unlocked device encryption does not protect |
| Secure Behaviour | Choosing quick unlocking to make a short lock sustainable |
Reference level: FL3 — Autonomous.
Summary
- The system does not know whether you are there: it only counts input events.
- The two timers run in sequence: the real window is their sum.
- On an unlocked device the encryption keys are in memory: the data is in the clear.
- Locking interrupts nothing: the applications keep working.
- Biometrics exist to make a short timeout sustainable.
One thing to do today. Add up your two timers on your computer. If the total is more than two minutes, your real window is longer than the one you thought you had set.
Related content
- Screen lock timeout — the recommendation this expands on
- How to set up automatic locking — where to act concretely
- Impact of leaving your screen unlocked — why the real window counts
- Proximity attacks — what takes advantage of physical closeness
Related resources
Short reads from the Resources section, for anyone who wants to stop on a single aspect:
Start with the first step: the Cyber Welfare Programme guides you free of charge, one recommendation at a time.
