Safeguard 4.3: Configure Automatic Session Locking on Enterprise Assets

Safeguard 4.3 requires you to configure enterprise assets to automatically lock user sessions after a defined period of inactivity, and to prove the setting is enforced consistently across your fleet. Operationalize it by standardizing lock thresholds, deploying them through centralized configuration management, and retaining recurring evidence that endpoints, servers, and virtual desktops actually comply. ¹

Key takeaways:

• Define a lock-after-inactivity standard by asset type and risk tier, then enforce it centrally. ¹
• Treat “configured” as “measurably enforced”: you need fleet-wide reporting plus exception handling. ¹
• Keep recurring evidence (policies, MDM/GPO profiles, and compliance reports) to pass audits quickly. ¹

Session locking is a basic control with outsized audit visibility: if a device is unattended and unlocked, an attacker or insider can access data, email, admin tools, and cached sessions without needing credentials. Safeguard 4.3 focuses on enterprise assets, so the intent is not “tell users to lock their screens,” but to enforce locking through technical configuration. ¹

For a CCO, GRC lead, or security compliance owner, the fastest path is to (1) define a clear standard (what locks, when, and what requires re-authentication), (2) push settings through your endpoint and identity tooling, and (3) continuously validate compliance with reporting that an auditor can understand. The common failure mode is documentation without operational proof: a policy that says “lock after inactivity,” but no centralized configuration object, no coverage metrics, and no exception register. ¹

This page translates the safeguard into requirement-level steps you can assign to endpoint engineering, IAM, and IT operations, with an evidence package that holds up under internal audit or external assessment. ¹

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 4.3 implementation expectation (Configure Automatic Session Locking on Enterprise Assets).” ¹

What the operator must do: Configure enterprise-managed assets so that user sessions automatically lock after inactivity. “Configure” implies a technical enforcement mechanism (for example, MDM, Group Policy, configuration profiles, or equivalent) rather than user training alone. You must also be able to show the setting is deployed, effective, and monitored over time. ¹

Plain-English interpretation (what this means in practice)

You need a documented, centrally enforced configuration that:

1. Locks the session after a defined idle time, and
2. Requires the user to re-authenticate to resume work, and
3. Applies to the enterprise asset population in scope, with tracked exceptions. ¹

A practical reading: if a laptop, workstation, VDI session, or shared kiosk can sit unattended while still granting access to enterprise resources, you have not met the intent. ¹

Who it applies to

Entity scope

• Enterprises and technology organizations adopting CIS Controls v8 as a security baseline or assessment framework. ¹

Operational scope (assets and environments)

Include any enterprise asset where a human session can remain active:

• Corporate endpoints (Windows/macOS/Linux workstations and laptops)
• Virtual desktops and published apps
• Servers with interactive logon (admin jump hosts, terminal servers)
• Shared devices (lab machines, call-center endpoints, conference-room PCs)
• Cloud-hosted desktops and managed workspaces (where you control session policy)

Exclude only what you truly cannot control, and capture those as formal exceptions (see “Evidence” and “Mistakes”). ¹

What you actually need to do (step-by-step)

Step 1: Define the lock standard (one page, operator-ready)

Write a short standard that answers:

• Trigger: inactivity-based lock (not just screen saver)
• User experience: lock screen plus re-authentication required
• Scope: which asset classes must comply
• Exceptions: allowed only with documented business need and compensating controls

Keep it implementable. Endpoint teams need explicit settings to configure, not general language. ¹

Decision points to settle early (reduce rework):

Topic	Options you must choose	Implementation owner
Idle timeout by asset type	One standard value or tiered by risk/role	GRC + Endpoint Engineering
Re-auth requirement	Password, MFA re-prompt in specific contexts, smart card	IAM + Endpoint Engineering
Shared devices	Tighter lock + restricted local accounts	IT Ops
Admin/jump hosts	Aggressive lock + privileged session controls	SecOps/IAM

(Framework driver: configure automatic session locking on enterprise assets. ¹)

Step 2: Inventory and segment in-scope assets

You need a list of endpoints and other enterprise assets where session locking must be enforced. If you cannot produce a population list, you cannot produce meaningful compliance evidence.

Minimum segmentation that works in audits:

• Endpoints (by OS)
• VDI / DaaS
• Servers with interactive logon enabled
• “Special purpose” endpoints (kiosks, labs, manufacturing floor)

Tie the inventory source to your system of record (CMDB, MDM, EDR console). ¹

Step 3: Implement technical enforcement centrally

Pick the control plane per environment, then implement as code or managed policy:

• Windows: Group Policy / MDM policy enforcing interactive logon inactivity limit and lock screen behavior
• macOS: MDM configuration profiles enforcing screen lock and password delay
• Linux: configuration management enforcing desktop environment lock policies (where applicable)
• VDI: platform policy for session timeout and lock behavior
• Jump hosts: hardened baseline plus restricted interactive use

Your goal is single-source enforcement per platform, not manual local configuration. ¹

Step 4: Validate effectiveness (don’t stop at “deployed”)

For each platform, validate:

• Policy is assigned to the right groups
• Devices report successful application
• Spot-check confirms the session locks after the configured idle period
• Re-auth is required after lock

Use a two-layer approach:

1. Automated compliance reporting from MDM/GPO/endpoint tooling, and
2. Targeted verification for high-risk segments (admins, finance, production). ¹

Step 5: Handle exceptions with governance that auditors accept

Create an exception workflow that records:

• Asset identifier, owner, and business justification
• Time-bounded approval
• Compensating controls (examples: physical controls, restricted network access, enhanced monitoring)
• Revalidation cadence

Exceptions are normal; undocumented exceptions are audit findings. ¹

Step 6: Operationalize recurring evidence capture

This safeguard commonly fails on “show me.” Set a recurring evidence job:

• Export compliance posture reports by platform
• Retain policy configuration snapshots (GPO/MDM profile versions)
• Keep a changelog for baseline updates
• Track remediation tickets for noncompliant devices

Daydream can help here by mapping Safeguard 4.3 to a documented control operation and structuring recurring evidence capture so your audit package stays current without quarterly fire drills. ¹

Required evidence and artifacts to retain

Maintain an evidence folder (or GRC control record) with:

1. Control narrative (1–2 pages)

• Scope definition (asset types included/excluded)
• Enforcement mechanisms per platform
• Roles and responsibilities
• Exception process ¹

2. Configuration proof

• GPO/MDM configuration exports or screenshots showing the relevant settings
• VDI/session policy settings export
• Baseline/hardening standard referencing session lock ¹

3. Population + coverage

• Asset inventory extracts showing in-scope counts by platform
• Group assignment logic (dynamic groups, OU structure, device tags) ¹

4. Compliance reporting

• Automated reports showing compliance status over time
• Evidence of remediation actions for failures (tickets, change records) ¹

5. Exceptions register

• Approved exceptions with compensating controls and expiration dates ¹

Common exam/audit questions and hangups

Auditors and assessors tend to ask:

• “What is your session lock standard, and who approved it?”
• “Show me how it is enforced technically, not just in policy.” ¹
• “What percentage of devices are compliant?” (Answer with your measured report; don’t guess.)
• “How do you ensure admins/jump hosts follow the same control?”
• “How do you prevent local users from changing the setting?”
• “How do you handle kiosks, lab devices, and shared endpoints?”
• “Show exceptions and compensating controls.”

Hangups that slow reviews:

• Evidence that shows settings exist, but not that they apply to the full population
• Incomplete scoping (laptops covered, VDI not addressed)
• One-time screenshots with no proof of recurrence ¹

Frequent implementation mistakes (and how to avoid them)

1. Relying on user training instead of enforcement
   Fix: require centralized policy objects with reporting. ¹

2. No re-authentication after lock
   Fix: test that unlock requires credentials; document the setting per OS/VDI.

3. Ignoring privileged and shared environments
   Fix: explicitly include jump hosts, VDI, and kiosks in scope; if excluded, document why and how risk is reduced. ¹

4. Local overrides allowed
   Fix: enforce via MDM/GPO with settings locked down; validate users cannot weaken the timeout.

5. No exception governance
   Fix: formal register, expiration, and compensating controls tied to a ticket or risk acceptance. ¹

Enforcement context and risk implications

No public enforcement cases are provided for this specific safeguard in the supplied source catalog. Treat it as a baseline security hygiene requirement: failure increases the likelihood of unauthorized access through unattended sessions, especially in shared workspaces, open offices, and remote work settings. The compliance risk is also practical: assessors commonly test session lock quickly during walkthroughs, and gaps are easy to demonstrate. ¹

Practical 30/60/90-day execution plan

Use phases to avoid calendar promises you can’t keep, while still driving urgency.

First 30 days (stabilize scope + baseline)

• Assign owners: Endpoint Engineering (enforcement), IAM (re-auth policy), GRC (standard + evidence).
• Publish the session lock standard with scope and exception rules. ¹
• Identify enforcement tooling per platform (MDM, GPO, VDI policy).
• Pull an inventory of in-scope assets and segment by OS and environment.
• Draft the evidence checklist and create a control record in your GRC system.

Days 31–60 (deploy + measure)

• Implement the configuration baseline in a pilot ring for each OS and VDI.
• Validate technical behavior with spot checks in each segment.
• Roll out broadly with change control and communications.
• Stand up recurring compliance reporting exports and an exceptions register. ¹

Days 61–90 (close gaps + make it audit-ready)

• Remediate noncompliant assets; document root causes (unsupported OS, unmanaged devices, conflicting policies).
• Formalize exception approvals with compensating controls and expirations.
• Package audit evidence: standard, configurations, reports, inventory coverage, and exception log.
• If you use Daydream, map Safeguard 4.3 to a documented control operation and schedule recurring evidence capture so you can answer audits with current, consistent artifacts. ¹

Frequently Asked Questions

Do we have to apply session locking to servers?

Apply it anywhere interactive user sessions occur, especially admin jump hosts and terminal servers. If a server truly has no interactive logon, document that assumption and validate it periodically. ¹

What about developers who complain session lock interrupts workflows?

Treat that as an exception request, not an informal bypass. Approve only with documented justification, compensating controls, and an expiration date so you can revisit the risk. ¹

Is a screensaver with a password good enough?

It can be, if it reliably triggers on inactivity and requires re-authentication. Your evidence should show the enforced setting and that users cannot disable or delay it locally. ¹

How do we prove compliance without manual screenshots?

Use centralized reporting from your endpoint management and VDI platforms, then retain periodic exports plus the configuration profile/GPO artifacts. Manual screenshots work only as supplemental spot checks. ¹

Do shared kiosks need different settings?

Usually yes, because unattended access risk is higher on shared devices. Define a separate kiosk baseline and restrict local accounts; document the rationale and configuration in the same control record. ¹

What’s the minimum evidence an auditor will accept?

A written standard, the enforced configuration objects, proof they apply to the in-scope population, recurring compliance reports, and a controlled exception register. Missing recurring evidence is the most common gap. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8