Safeguard 4.3 Session locking: CIS Controls requirements and evidence

What Safeguard 4.3 asks for and why assessors care about it

Safeguard 4.3 asks you to configure enterprise assets so that a session locks automatically after a defined period of inactivity. CIS sets the maximum at 15 minutes for general-purpose operating systems and 2 minutes for mobile end-user devices. The Safeguard sits in the Devices asset class and the Protect security function, and it belongs to all three Implementation Groups, so it is part of IG1 essential cyber hygiene that every enterprise is expected to meet. An unattended session that stays unlocked gives anyone standing at the desk, or anyone who picks up a lost laptop, the same access the user had, which is why assessors treat it as a basic control rather than an advanced one. The requirement is simple to state and harder to keep true. Settings drift across a fleet when images, group policies, mobile profiles and manually built machines each carry a different timeout. Shared kiosks, meeting-room displays and point-of-sale terminals often have timeouts disabled for convenience. Unmanaged or bring-your-own devices may never receive the policy at all. Your first decision is therefore which asset populations are in scope and which management tool enforces the setting on each one, and your second is how you will show that the enforced value matches the CIS maximum on every device, not just on the reference build. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, so meeting Safeguard 4.3 does not by itself satisfy a framework that cites it. The CIS Controls Assessment Specification defines what to measure for this Safeguard, including the properly configured assets metric, but it does not prescribe the tool or method. Confirm with your assessor or the relevant framework owner which evidence they accept, and check the Navigator mappings for the frameworks you report against before assuming a CIS result carries over.

Which devices and teams fall under Safeguard 4.3

Safeguard 4.3 applies to every enterprise asset where a user can start an interactive session, so the scope starts with an accurate picture of those assets. The decisions below determine how much work the measurement requires and which teams need to own each part.

Workstations and laptops

Desktops and laptops used by staff are the most common in-scope assets and usually the largest group. Each one needs the lock timeout set at or below 15 minutes on general-purpose operating systems, applied through a managed policy rather than by each user. Check whether the setting is enforced centrally, whether users can override it locally, and whether machines outside directory or device management still receive it.

Servers with interactive sessions

Servers count when administrators or operators log in interactively at a console, through a remote desktop, or through a terminal that stays open. Headless servers that only run services and accept no interactive logins are typically assessed differently, so confirm each server's role before deciding. Coordinate the timeout with the teams that run administrative sessions, because a short timeout can interrupt long-running maintenance work.

Mobile end-user devices

Phones and tablets issued or managed by the enterprise fall under the stricter limit of no more than 2 minutes. This is a different configuration path from desktops, usually delivered through a mobile device management profile. Confirm that the mobile fleet is covered in the enterprise asset inventory and that the profile is actually applied to each enrolled device.

Shared and kiosk endpoints

Shared workstations, clinic terminals, warehouse scanners and kiosks often have a generic or shared login, which makes the lock timeout harder to tie to an accountable user. Decide who owns the setting for each device class, and document any exception with compensating controls such as physical access limits. Expect these endpoints to be missed in manual reviews because they are rarely treated as personal computers.

Bring-your-own-device scope

Unmanaged personal devices used to access enterprise resources are the scoping decision that changes the work most. If they are not in the enterprise asset inventory, the organization must decide whether they are in scope at all, and an assessor will want to see that decision recorded. Ask whether personal devices can reach enterprise data, and whether the organization can enforce a lock timeout on them or only restrict the access they get.

Prerequisite inventories and processes

The CIS Controls Assessment Specification lists Safeguards 1.1 (enterprise asset inventory), 2.1 (software inventory) and 4.1 (secure configuration process) as prerequisites for measuring Safeguard 4.3, because they produce the data the measurement depends on. Without a current asset list, the population of devices cannot be counted, and without a documented configuration process, the timeout value has no approved baseline to test against. Confirm these three records exist and are current before scoping the lock measurement.

How an assessor tests session locking against the CAS

This table walks through how an assessor works through Safeguard 4.3 using the CIS Controls Assessment Specification, from the six measures and the single properly configured assets metric to the inputs requested and the findings that most often appear. Read it as a preparation checklist: the left column names the step, and the other columns show what to have ready and where evidence usually falls short.

Assessment step	What the assessor looks for	Common finding or gap
Scope and prerequisites	Asset inventory from Safeguard 1.1, software inventory from Safeguard 2.1 and a documented secure configuration process from Safeguard 4.1 that the assessor can trace to the measurement	Inventory exists but does not list the endpoints that the lock settings are actually applied to
Measure one: general-purpose OS lock threshold	Configured inactivity period on desktops and laptops no greater than 15 minutes, applied through policy rather than per-user settings	Lock set to 30 minutes or left at a default that was never reviewed
Measure two: mobile end-user device threshold	Configured inactivity period on mobile devices no greater than 2 minutes, enforced through mobile device management or equivalent	Mobile fleet has no enforced policy, or thresholds differ between iOS and Android groups
Measures three to six: enforcement and coverage	Evidence that the setting is enforced on each asset class, cannot be silently overridden by the user, and survives reimaging or enrollment	Settings exist in a golden image but drift on endpoints built outside the standard image
Combined metric: properly configured assets	A count of assets that meet the thresholds divided by the assets in scope, so the assessor can see the share that pass	Metric is never calculated, so the organization cannot say how many devices fail
Exceptions and approvals	A documented, approved exception with a business reason, an owner and a review date for any device that cannot meet the threshold	Exceptions exist in conversation or on tickets but no formal approval or expiry is recorded
Sampling of devices	The assessor selects a sample across device types, operating systems and locations, then checks the live setting or a policy export for each sampled device	Sample reveals assets that were not in the inventory or policy scope, which widens testing

How to implement automatic session locking step by step

This sequence takes Safeguard 4.3 from a documented starting point to a verified, exception-controlled state in which enterprise assets lock after inactivity within CIS's maximum thresholds. Each step produces a record an assessor can follow.

Confirm inventory and secure configuration process
Before setting any lock timeout, confirm that the enterprise asset inventory (Safeguard 1.1), the software inventory (Safeguard 2.1) and the secure configuration process (Safeguard 4.1) exist and are current. The Assessment Specification treats these as prerequisites because the measurement for Safeguard 4.3 depends on knowing which assets exist and which platforms they run. The output is a confirmed list of in-scope device types, grouped into general-purpose operating systems and mobile end-user devices, with an owner for each group.
Set lock thresholds in the baseline
Write the inactivity lock thresholds into the secure configuration baseline for each platform. CIS sets the maximums at 15 minutes for general-purpose operating systems and 2 minutes for mobile end-user devices, so the baseline should state values at or below those limits. The security owner approves the baseline, and the approval is recorded with its version and date. The output is a per-platform baseline document where every platform has an explicit timeout value and a named approver.
Deploy settings through management tooling
Push the baseline settings using the tooling the organization already runs: mobile device management for phones and tablets, Group Policy or equivalent directory policy for Windows endpoints, and configuration management for Linux and macOS servers and workstations. Apply the settings to device groups rather than individual machines so that new enrollments inherit them. The output is a deployment record showing which policy or profile targets which group and when it was last applied.
Verify settings with automated checks
Run automated checks that read the effective lock timeout on each device and report pass or fail against the baseline. Wazuh Security Configuration Assessment can evaluate endpoints against YAML policies, many of them based on CIS benchmarks and extendable with custom checks. Fleet policies can ask devices yes or no questions through osquery and show which devices pass or fail each policy. Confirm with the tool vendor which lock-timeout checks ship by default before relying on them. The output is a dated compliance report with pass and fail counts per device group.
Investigate and remediate failing devices
Review every failing device from the verification report and determine whether the cause is a deployment gap, a conflicting local policy, an unmanaged device or a platform that cannot apply the setting. Remediate deployment gaps by re-applying the policy and re-running the check. Record each device that remains non-compliant with its reason. The output is a remediation log showing each failure, the action taken and the re-test result.
Document exceptions with approval
Where a device cannot meet the threshold, record a formal exception that names the asset, the platform, the setting that deviates, the compensating control, the business justification and the approver. Exceptions should have a review date and an owner. The output is an exception register that shows every deviation from the 15-minute and 2-minute maximums, approved and reviewed, rather than unexplained gaps in the reports.
Retain outputs for assessment
Keep the evidence trail in one location so an independent assessor can trace each step: the inventory references, the approved baseline, the deployment records, the dated verification reports, the remediation log and the exception register. Confirm with the organization's auditor which evidence format and retention period it requires, since those are set by the assessment engagement rather than by CIS. The output is an evidence pack that lets someone reconstruct the state of session locking on any date.
Repeat verification on a regular cycle
Schedule the automated checks to run on a recurring basis and reconcile the results against the exception register each cycle. New devices, OS upgrades and policy changes can silently reset timeouts, so the recurring run is what keeps the measurement current. The output is a series of dated reports that show the metric (properly configured assets) holding steady or trending as expected, with any new failures routed back into the remediation step.

How the lock timeout is set and enforced across platforms

Safeguard 4.3 is written as a outcome rather than as a setting, so the same CIS maximums of 15 minutes for general-purpose operating systems and 2 minutes for mobile end-user devices have to be met through whatever mechanism each platform offers. Windows, macOS, Linux distributions and mobile operating systems each expose inactivity locking through different components: local security policy or group policy, configuration profiles, desktop environment settings or device management policy. The timeout is enforced by the platform, not by the CIS document, so the first task is to inventory which lock mechanism governs each device family and record the exact setting name and value in use. Confirm those names and values with the current vendor documentation for each operating system version, because they change between releases and cannot be taken from this page.

The 2-minute mobile threshold is stricter because a phone or tablet is carried outside controlled premises, is more likely to be lost or left unattended, and is often used in short bursts where a lock screen is the only barrier between a stranger and enterprise mail or messaging. The 15-minute general-purpose ceiling reflects desktops and laptops that usually sit in controlled offices, though CIS treats it as a maximum, not a target. Where a laptop is used in public places, a shorter value may be the defensible choice even though the Safeguard allows more. Document the reasoning for each asset class so an assessor can see that the chosen value was a decision rather than a default.

Inactivity locking interacts with several other settings that can silently defeat it. A screen saver that locks on resume may be governed separately from the operating system session lock, and a display that stays on because of a presentation or media setting may never count as idle. Sleep and hibernate behavior matters too: a device that sleeps without requiring a password on wake can resume without any lock check. Remote desktop sessions need their own review, since a disconnected session may keep running, or a reconnect may bypass the local lock, depending on the server configuration. Test each scenario on a representative device of each platform and record the result, because a policy that appears correct on paper can fail in these transitions.

Evidence that proves session locks are configured and kept current

An assessor testing Safeguard 4.3 wants proof that the timeout is set on every in-scope asset and that it stayed set across the review period, not just on the day someone checked. The cards below cover the configuration exports, device-management records, scan results, exceptions and change history that together show both points, and how to keep them current between audits.

Exported configuration baselines with timeout values

Export the effective screen lock or inactivity timeout from each operating system image or hardening baseline, and record the value in minutes next to the asset class it applies to. An assessor compares that value against the Safeguard's maximum of 15 minutes for general-purpose operating systems and 2 minutes for mobile end-user devices. Check that the export shows the effective setting after policy inheritance, not only the value typed into a template. Keep the baseline version and date so it can be matched to the asset state on a given day.

Policy and group policy exports

Export the directory or configuration policy objects that deliver the lock setting, such as Active Directory Group Policy Objects, Intune configuration policies or Linux configuration management modules. Include the link or scope record showing which groups or device sets each policy applies to. A policy that exists but is linked to no active group proves nothing for the assets it was meant to cover. Compare the exported timeout against the baseline so any drift between the written standard and the deployed policy is visible.

MDM profile records for mobile devices

For phones and tablets, the mobile device management profile is the primary evidence. Retain the profile definition, the assignment record and the device-level install status showing the inactivity lock is enforced at or under the 2-minute maximum. Confirm with your MDM vendor whether the lock timeout is enforced as a required restriction or can be overridden by the user, because that determines whether the profile alone is sufficient. Record which mobile devices are unmanaged, since the Safeguard's requirement cannot be evidenced for them by the profile.

Automated compliance scan results

Automated configuration assessment produces the most current evidence that the setting is in force on each asset. Wazuh Security Configuration Assessment checks endpoints against YAML policies, shipped mostly based on CIS benchmarks and extendable with custom checks, and recommends remediation for failures. Fleet policies ask yes or no questions of devices through osquery and show which devices pass or fail each policy. Retain the per-asset pass and fail lists with timestamps, because a single passing screenshot cannot show the state across the audit period.

Exception register entries with approvals and expiry

Some assets will not meet the timeout, such as kiosks, lab machines or industrial systems where an abrupt lock would disrupt operation. Each exception should name the asset, the timeout actually in force, the compensating measure, the business owner who approved it, and an expiry date after which the exception is reviewed or closed. Check that the register links to the scan results, so that a failing asset appears as an accepted exception rather than an unexplained gap. Ask your assessor early which exception practice they accept, since the wording of approval and review rules varies by organization.

Change records for timeout modifications

Every change to the lock timeout, whether in a baseline, a policy object or a device profile, should appear in the change management system with the requester, the approver, the old and new values, and the rollout date. Change records show that a weakened timeout was not introduced quietly, and they let you match a scan failure to a specific change. Review changes that touched the lock setting during the audit period against the exception register, because an unapproved increase in the timeout is a common reason an assessor raises a finding.

Scheduled scans and retained snapshots

Evidence goes stale quickly, so schedule the configuration scans and the MDM compliance reports to run on a fixed cadence and store each output in a retained, read-only location with its date. Keep periodic snapshots of the baseline and policy exports as well, so you can show the state at any point in the review period. Confirm your retention requirement with the auditor or the regulation you are meeting, because the period is set by that framework rather than by CIS. Test one restore of an old snapshot before the audit, so that the evidence can be produced on request.

What meeting Safeguard 4.3 costs in money and effort

This table breaks down the cost and effort components of meeting Safeguard 4.3, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to structure a quote request, since no price list is published for this work and the figures depend on your environment and scope.

Cost component	Who is paid or who carries the effort	One-time or recurring	What drives it up or down
Endpoint management or MDM licenses	Software vendor, or none if a self-hosted open-source platform is used	Recurring if commercial, typically per device	Fleet size and platform mix; open-source tooling can remove this line but adds support effort
Compliance scanning tooling	Vendor, or none if open-source checks are used	Recurring if commercial, one-time setup otherwise	Number of policies needed and how many device types must be checked
Baseline design for lock timeouts	Internal staff or implementation partner, fixed scope	One-time	Number of operating systems, mobile platforms and whether the 15 and 2 minute maximums must be set per asset class
Drift detection and remediation	Internal platform or security team	Recurring	Unmanaged devices, user overrides and frequency of OS updates that reset settings
Evidence collection and upkeep	Internal compliance staff	Recurring	How often exports are needed and whether reports are generated automatically or by hand
External review or testing	Independent assessor or consultant, by written scope	Recurring if the assessment cycle repeats	Scope of sampled devices and whether the review covers prerequisite inventories (Safeguards 1.1, 2.1, 4.1)
Auditor sampling effort	Auditor fees, set by the auditor's engagement terms	Recurring per assessment cycle	Number of devices sampled and quality of the evidence the organization can produce on request

Open-source tools that produce session locking evidence

Wazuh's Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. Most shipped policies are based on CIS benchmarks, and organizations can extend them with custom policies that check files, directories, registry keys and running processes. For session locking, the relevant output is a per-endpoint pass or fail result against the inactivity setting the policy checks, along with recommended remediation text. Those results can be retained as dated scan records that show the state of each asset at a point in time.

Evidence produced: Scan results per endpoint showing which checks passed or failed, with timestamps that can be kept as assessment records.
Policy basis: Shipped policies are mostly based on CIS benchmarks, so confirm which benchmark version and which screen lock values each policy tests against the 15 and 2 minute maximums.
Custom checks: Add a custom YAML policy when the shipped checks do not cover a mobile device type or an internal standard, and version-control it.
License caveat: Wazuh is licensed under GPL-2.0-only. Review what that license requires if you modify and distribute the software, and get legal advice for your own use case.
Scope limit: The scan reports what it finds on monitored endpoints. Confirm endpoint coverage before relying on it as evidence for the full asset inventory.

Confirm with your own environment which endpoints the Wazuh agent covers and whether the shipped policy values match your documented standard.

Where session locking programs usually fall short

Session locking looks simple on paper, yet most failures happen at the edges: devices nobody inventoried, mobile devices held to desktop settings, users and kiosks that quietly override policy, and exceptions with no paper trail. Each gap below undermines the measurement Safeguard 4.3 depends on, and each one has a specific action to close it.

Unmanaged devices outside the inventory

A lock policy cannot be verified on a device nobody tracks. Laptops bought outside procurement, shared lab machines and personal devices used for work often sit outside the enterprise asset inventory that Safeguards 1.1 and 4.1 rely on. Reconcile your directory and management consoles against the asset inventory, then decide which unlisted devices are in scope before you report a compliance percentage.

Mobile thresholds set to desktop values

The CIS maximum for mobile end-user devices is 2 minutes, while general-purpose operating systems allow up to 15 minutes. Many programs apply one profile to every endpoint, which leaves phones and tablets locking far too slowly. Build separate configuration profiles for each device class and check the effective timeout on a sample of each, not only the policy definition.

User and kiosk overrides

Users can often change screen saver or sleep settings locally, and kiosk, digital signage and shared-workstation modes may disable locking entirely. Either case means the configured value is not the value in effect. Enforce the setting through central management so it cannot be changed locally, and document every kiosk that runs without a lock with its compensating control, such as physical controls or automatic session reset.

Undocumented exceptions

Legacy systems, clinical devices and production consoles frequently receive informal exemptions from a manager or an administrator. Without a record, nobody can tell whether an exception was approved, how long it lasts or whether it still applies. Keep an exception register with the asset, the reason, the compensating measure, the approver and an expiry date, and review it on the same cycle as your secure configuration process.

No recurring evidence

A session lock setting checked once during rollout proves little about the next year. Devices get reimaged, policies drift and new device classes appear without anyone updating the rule. Schedule a recurring export of compliance results per device and per policy, keep dated snapshots, and retain them with the configuration baseline so an assessor can see the state over time, not only at one moment.

Questions buyers ask about Safeguard 4.3

How much effort does Safeguard 4.3 take to implement in-house?

In-house effort is usually modest for the setting itself and larger for proving it across the whole estate. The configuration is an inactivity timeout pushed through directory group policy, mobile device management profiles or a local configuration baseline, so the build work is small on any single platform. The effort grows with the number of operating systems, device types and business units you must cover, and with the exceptions you need to document and justify. Plan staff time for the initial configuration, testing on each platform, drift checks after new builds and periodic exception reviews. Most of the cost is internal labor. The first rollout is one-time work, while monitoring and exception handling recur. A partner's fixed-scope quote should itemize these tasks so you can compare it with your own estimate.

How long does it take to configure automatic session locking?

The duration depends on your environment, so ask for a timeline in the written scope before work starts. The main drivers are the number of enterprise assets, whether you already run central directory or device management, the maintenance windows available for change, and how much testing specialist systems need, such as kiosks, lab hosts or industrial devices that may not accept the standard settings. Evidence collection also takes time if you must show a history of compliance rather than a single snapshot. If the asset inventory (Safeguard 1.1), software inventory (Safeguard 2.1) or secure configuration process (Safeguard 4.1) does not exist yet, those prerequisites can extend the schedule because they supply the data the measurement depends on. DeployOpen's engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

Can our own team configure session locking without an outside partner?

Often yes, if you already run a directory service or mobile device management platform and have staff who administer it. The requirement is a configuration setting with a maximum of 15 minutes on general-purpose operating systems and 2 minutes on mobile end-user devices, so the change itself is within reach of most IT teams. A partner adds value when the estate is mixed, when there is no central management, or when you need the evidence to be consistent for an assessor. Tools can help verify the result. Wazuh's Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and Wazuh's documentation describes how it works. Fleet policies answer yes or no questions as osquery queries and show which devices pass. Confirm platform coverage and licensing before you rely on either tool. The organization always owns the control.

Does CIS certify that we meet Safeguard 4.3?

No. The Center for Internet Security publishes the CIS Critical Security Controls and the CIS Controls Assessment Specification, which describes what to measure for each Safeguard. CIS does not certify organizations against them. Any formal report or attestation must come from an independent auditor or assessor, and DeployOpen prepares systems and evidence but does not issue reports or certificates. CIS also states that the Controls do not replace regulatory, compliance or authorization schemes. The Controls content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, so commercial use requires CIS's prior approval. CIS Controls Accreditation applies to CIS SecureSuite member organizations that provide implementation, auditing or assessment services, and CIS lists an application fee of $1,500 for CREST members and $2,500 for non-members. Ask any provider which of these roles it holds.

What does our staff need to provide for this safeguard?

Your staff owns the decisions and the day-to-day running of the setting, so identify these roles before the engagement starts:

Directory or device management administrators, who own the policy objects, apply the timeout to the right groups and keep the configuration under change control.
Endpoint or IT operations staff, who deploy the setting, test it on each platform and handle exceptions for systems that cannot meet the limit.
A security or compliance lead, who owns the documented secure configuration process, reviews exceptions and decides what evidence an assessor will receive.
Application and specialist system owners, who confirm whether kiosks, lab hosts or industrial devices can accept the timeout and document any compensating controls.

The CIS Controls Assessment Specification measures Safeguard 4.3 through six measures combined into one metric, properly configured assets, so each role should know which of those measures it supports.

How does Safeguard 4.3 map to ISO 27001, PCI DSS and NIST SP 800-53?

CIS's own mappings in the CIS Controls Navigator for v8.1 link Safeguard 4.3 to NIST SP 800-53 Rev. 5 controls AC-2(5), AC-11, AC-11(1) and AC-12, to ISO/IEC 27001:2022 Annex A 8.5 and 8.9, and to PCI DSS v4.0 requirement 8.2.8. These are CIS's mappings, so treat them as a starting point for your own control matrix rather than as proof that one control satisfies another framework. Each framework has its own assessment procedures, and an assessor will decide whether your evidence meets them. Check the current mappings directly in the CIS Controls Navigator before you record them in an audit file, because the Navigator covers 30 frameworks and versions and is the authoritative source for the mapping.

How DeployOpen prepares session locking evidence

DeployOpen starts with a written scope that names the enterprise asset classes in play for Safeguard 4.3 Configure automatic session locking on enterprise assets: general-purpose workstations and servers, and mobile end-user devices. The scope also records which devices fall under each lock limit, because the CIS maximums differ: no more than 15 minutes of inactivity on general-purpose operating systems and no more than 2 minutes on mobile end-user devices. Agreeing that split in writing before work begins prevents a common assessment gap, where one device group is measured against the wrong threshold. The scope also states which Safeguards must be in place first. The CIS Controls Assessment Specification lists the asset inventory (Safeguard 1.1), the software inventory (Safeguard 2.1) and the secure configuration process (Safeguard 4.1) as prerequisites, so DeployOpen confirms with you that those inputs exist or will be produced before the lock settings are measured. Most engagements are fixed-scope, and a quote follows from this written scope.

DeployOpen then deploys and hardens the tooling inside your own cloud accounts, data centers or air-gapped network. For Windows, Linux and macOS hosts, a configuration assessment tool such as Wazuh Security Configuration Assessment can check screen lock settings against YAML policies that are based mostly on CIS benchmarks and can be extended with custom checks. For a yes or no view of each device, a query-based platform such as Fleet can run an osquery policy that asks whether an inactivity lock is set and show which devices are passing or failing. Your team must confirm that each tool supports the platforms and mobile device management route you use, since device coverage varies. DeployOpen configures the tool's access controls, retention settings and data flows so that the scanning platform is itself governed under your own access and change processes.

DeployOpen prepares the evidence package that the independent assessor will review, including policy extracts, scan configurations, dated pass and fail reports, exception records with owners and remediation dates, and a mapping from the six CIS measures to the artifacts that show each one. The evidence is produced by your systems, not by DeployOpen. Ask the assessor, before the work starts, which evidence format and sampling approach they expect, because that decides how often reports must be exported and retained. DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body can do that. Confirm with your assessor which framework mappings they will accept, since the CIS Controls Navigator links Safeguard 4.3 to several external controls.

Safeguard 4.3 Configure automatic session locking on enterprise assets