Skip to content
Cryptography
ASD ISMISM-0489

ASD ISM 0489 Four-hour cached SSH private key lifetime and screen locks

What it says

When SSH-agent or similar key caching applications are used, cached private keys have a maximum lifetime of four hours and, where applicable, screen locks are used on workstations and servers.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Limits how long SSH-agent style tools can hold an unlocked private key (four hours at most) and pairs that with screen locks so an unattended session cannot be used to reach other systems.

SSH-agent and similar key caching applications hold a decrypted private key in memory so a user does not have to enter the key passphrase every time they connect. That convenience creates a window in which anyone with access to the running session can use the key without knowing the passphrase. This control keeps that window small. Where key caching applications are used, a cached private key may live for no more than four hours before it must be unlocked again. In addition, where applicable, workstations and servers must use screen locks so that an unattended session with cached keys cannot be picked up by someone walking past, or by another user or process on a shared server. Why it matters: an SSH private key is often the door to many servers at once. If a key sits unlocked in an agent for days, a stolen laptop, an unattended desk or a compromised session gives an attacker the same access as the key owner, with no passphrase prompt to stop them. Bounding the cache lifetime and locking the screen mean the key is only usable by the person who unlocked it, and only for a short time.

Why it matters

Without a cached key lifetime and screen locks, an unlocked SSH private key can remain usable indefinitely on an unattended or compromised workstation or server. An attacker, a colleague or malware with access to that session can authenticate to every system the key is trusted by, without ever needing the passphrase, turning a single unattended session into lateral movement across the environment.

How to implement

  1. System administrators configure the SSH-agent (or equivalent key caching tool) on every managed workstation and server with a default maximum key lifetime of four hours or less, for example by starting OpenSSH ssh-agent with a default timeout (ssh-agent -t 4h), adding keys with a lifetime (ssh-add -t 4h), or setting AddKeysToAgent to a lifetime value in the SSH client configuration.

  2. Endpoint engineers push the agent lifetime setting through the device management platform or configuration management tool so it is applied consistently and cannot be silently removed by users.

  3. Security engineers review any 'similar' key caching applications in use (desktop keyrings, password manager agents, hardware token middleware) and set each to expire cached private keys within four hours, replacing tools that cannot enforce a lifetime.

  4. Desktop and server administrators enable inactivity screen locks on workstations and on servers with interactive sessions, and confirm that users can lock manually, so a session holding cached keys is not left open when unattended.

  5. Platform owners add both settings (four-hour agent lifetime and screen lock) to the standard operating environment build baselines and to the acceptance checklist for new hosts, so the control is inherited rather than applied case by case.

Keep it running

Day to day this control shows up in three places.

**Agent configuration.** SSH-agent and equivalent tools (for example, agents built into desktop keyrings, password managers or hardware token middleware) need a maximum key lifetime set to four hours or less. This is usually a default timeout applied when a key is added, plus a check that users cannot override it with an unlimited lifetime. Users will be prompted for their passphrase again after the timeout, which is expected behaviour, not a fault.

**Screen locks.** Workstations and servers that run key caching applications need screen locks applied where applicable. In practice this means an inactivity lock plus the ability to lock manually, and it applies to servers with interactive desktop or console sessions as much as to laptops.

**Ongoing checks.** Include the agent lifetime and screen lock settings in standard build and configuration baselines so new devices inherit them, and periodically confirm that running agents on sampled hosts are not holding keys beyond four hours. Where a tool cannot enforce a lifetime, treat that as a gap to fix or a reason not to use that tool for key caching.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the list of key caching applications approved and in use across workstations and servers, and the configuration that sets their maximum cached key lifetime.

    Look at

    Check that every agent in use has a defined lifetime and that the value is four hours or less, with no option for users to add keys with an unlimited lifetime.

    Good evidence

    Each key caching tool has a documented, centrally managed lifetime of four hours or less, and unmanaged or unlimited-lifetime tools are not permitted.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the configuration management or device management policy that deploys the agent lifetime setting.

    Look at

    Look at how the setting is applied, whether it is enforced or merely recommended, and whether compliance reporting shows the setting present on managed hosts.

    Good evidence

    The setting is pushed and enforced by a central tool, and compliance reports show it applied on the fleet rather than left to individual users.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the screen lock policy for workstations and for servers with interactive sessions.

    Look at

    Confirm inactivity locks are enabled and that servers where key caching applications run are included, not just laptops and desktops.

    Good evidence

    Screen locks are enforced on all workstations and on applicable servers, with the policy covering hosts that hold cached keys.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask to observe or sample running agents on a few workstations and servers.

    Look at

    Check that keys are added with a lifetime of four hours or less (for example, the ssh-add -t value or the agent default timeout on the running host) and that a key listed by the agent is absent from it once that timeout has passed.

    Good evidence

    Sampled hosts show keys with a bounded lifetime and prompt for the passphrase again after the timeout.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the standard operating environment build documentation and any exception register.

    Look at

    Check that the four-hour agent lifetime and screen lock settings are part of the baseline and that any exceptions are recorded, justified and time limited.

    Good evidence

    Both settings appear in the baseline, new hosts inherit them, and exceptions are rare and formally approved.

Mappings

Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.

ISO 27001

ISO/IEC 27001: 3 mappings

  • A.5.15Access control policies and proceduresPartially meets
  • A.8.1Protection of user endpoint devicesPartially meets
  • A.8.24Effective use of cryptography and key managementPartially meets

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.