AC-11 Device lock: requirements and evidence

What AC-11 device lock asks for and why assessors check it

A compliance lead or engineer responsible for AC-11 needs to show that an idle workstation or open session cannot be used by someone other than the person who started it. AC-11 asks the system to lock the device after an organization-defined period of inactivity, or when the user asks for a lock, and to keep it locked until the user gets back in through normal identification and authentication. The organization sets the inactivity period and the rules for who may lock what. The system must enforce the lock, not merely display a reminder. This matters because an unattended, unlocked session carries the privileges of the signed-in user, so anyone standing at the desk, in a meeting room or at a shared terminal inherits that access without ever authenticating. Unattended sessions are a common route for insider misuse and for accidental changes to records, which is why assessors treat the lock as a basic protection rather than a convenience setting.

The difficulty is rarely writing the policy. It is getting the same behavior across every device that holds sensitive sessions. Windows, macOS and Linux desktops each expose lock timeouts through different mechanisms (group policy, configuration profiles, desktop environment settings or display manager configuration), so one organization-wide value can be applied in some places and silently overridden in others. Shared workstations, kiosks, clinical or terminal-style devices and devices that run long unattended jobs raise harder questions: whether a lock should appear, what a user must do to unlock, and whether a shared account bypasses the lock entirely. The reader should confirm, for each device class, which setting governs the lock, who can change it and what the lock does to running processes.

Proving the setting holds across the fleet is the step that most often stalls an assessment. An assessor will ask for the configured value, the policy that enforces it and evidence that devices actually report it, not just a document that describes it. Before any assessment, pick a sample of device types, record the effective inactivity period on each and identify any exceptions with a documented reason and owner. Check whether the configuration is enforced centrally or depends on users, and whether a deviation would be detected. Compliance tooling that reports device configuration state, such as the open-source options described below, can supply that evidence once the expected value and the owner for each exception are agreed in writing.

Which systems and devices fall under AC-11 device lock

AC-11 applies to systems selected into the moderate or high baseline, and the device types inside those systems decide where the lock must actually run. The cards below separate the baseline decision from the endpoint, console, virtual desktop and third-party device questions that determine how the control is built and evidenced.

Baseline selection comes first

SP 800-53B selects AC-11 for the moderate and high baselines, so a system categorized as low impact does not inherit the control by default. The organization makes this call under its own system categorization and risk management process, not under a template. Record the impact level, the selected baseline and any tailoring decision in the system security plan so an assessor can trace why AC-11 is in or out of scope.

Privacy baseline does not apply

The privacy baseline in SP 800-53B does not select AC-11, so a system that is scoped only for privacy controls does not pick up this requirement. Teams that process personally identifiable information often assume privacy scope covers every access control, so confirm which baseline the system's security plan actually cites. Systems that also hold sensitive data at a moderate or high impact level still need AC-11 through the security baseline.

Laptops, workstations and thin clients

User endpoints are the most common place where AC-11 is tested, and assessors usually sample them directly. Confirm that the operating system or endpoint management policy enforces the inactivity lock and the user-initiated lock on every device class in scope, including thin clients that have minimal local configuration. Document the setting source, such as a group policy or mobile device management profile, because that source is what the assessor examines.

Kiosks and shared public terminals

Kiosks and shared terminals often run kiosk modes that suppress normal session controls, so the lock behavior can differ from a standard desktop. Decide whether a kiosk is an information system in the moderate or high baseline and, if so, whether its inactivity timeout and re-authentication step are defined and tested. Where a kiosk has no user authentication at all, check whether it falls under the permitted-actions control AC-14 instead.

Server consoles and administrative sessions

Server consoles, out-of-band management interfaces and administrator workstations are in scope when they accept interactive logons for systems in the baseline. Verify that the console lock is set in the operating system or management controller and that re-entry requires the same identification and authentication as normal access. Remote administrative sessions also depend on session controls, so cross-check these settings with the AC-12 and AC-17 implementations.

Virtual desktops and application-level locks

A lock can be enforced by the operating system inside a virtual desktop, by the virtualization layer, or by an individual application that keeps its own session. Identify which layer holds the authoritative session, because a locked application window on an unlocked desktop may not satisfy the requirement. Confirm the lock on the layer a user actually reaches, and test both the timeout and the user-initiated lock from the client side.

Contractor and third-party devices

Devices that the organization does not own, such as contractor laptops or vendor support sessions, are handled through the external systems control AC-20 and the agreements that govern them. Where such a device connects to a system in the moderate or high baseline, the organization must either verify that the device enforces an equivalent lock or restrict what it can reach. Ask vendors to state their lock configuration in writing and make the attestation part of the access agreement.

How an assessor tests the device lock control

This table walks through the three assessment methods in the SP 800-53A procedure for AC-11, showing what an assessor examines, asks and tests, the evidence each method produces and where lock settings most often fail. Read each row as a question the assessor will put to your team, and prepare the matching artifact before fieldwork begins.

Assessment method	What the assessor looks at	Evidence that satisfies it	Common finding
Examine: access control policy and session lock procedures	Whether the policy states an organization-defined inactivity period and a user-initiated lock, and whether procedures assign who sets and maintains the value	Approved policy with the defined inactivity period, procedure documents naming owners, and review dates	Policy states a period but no procedure says who changes it or how exceptions are approved
Examine: system design documentation and security plan	Whether the design describes the lock mechanism for each device class and how the lock persists until identification and authentication succeed	Design documents and system security plan entries covering workstations, mobile devices and any shared terminals	Design covers corporate laptops only, leaving kiosks, thin clients or mobile devices undocumented
Examine: system configuration settings	Whether the configured inactivity timeout and lock behavior match the defined value on the systems in scope	Exported configuration baselines, directory policy objects or management profile settings, with timestamps	Timeout set in a central policy but overridden locally, so the effective value differs from the documented one
Interview: system and network administrators	How the lock is configured, changed and verified, and how new devices pick up the setting	Administrator explanation supported by change tickets and the list of managed device groups	Administrators describe the setting from memory and cannot show which device groups inherit it
Interview: system developers	Whether applications with their own session handling honor the operating system lock and avoid bypassing it	Developer walkthrough of session handling code paths and documented lock behavior for each application	Custom applications keep sessions alive during activity elsewhere or resume without re-authentication
Test: lock mechanisms on sample devices	Whether the device locks after the defined period and on user request, and stays locked until the user authenticates again	Test records showing idle time, lock timestamp and the authentication prompt, for a sample of each device type	Lock triggers on Windows laptops but not on Linux workstations, macOS or mobile devices in the sample
Test: pattern-hiding display (AC-11(1), moderate and high baselines)	Whether the screen hides prior content while locked, so the image shows no residual session data	Screenshots or recorded tests of the locked screen on each device type in scope	Lock screen shows the last application window or a blurred but readable image
Test: lock across remote and virtual sessions	Whether remote desktop, virtual desktop and browser sessions follow the same lock rules as local sessions	Test results for each remote access path, with the timeout values in effect	Remote sessions have longer timeouts or no lock, which the local policy does not reflect

What the pattern-hiding enhancement changes for moderate and high systems

AC-11(1) is the part of AC-11 that changes what a locked screen may show. In SP 800-53B Release 5.2.0, the pattern-hiding display enhancement is selected in the moderate and high baselines, and the enhancement is not withdrawn. The base lock requirement stops access, but this enhancement adds a display requirement: once the device is locked, the screen must not keep showing the content, layout or activity that was visible before the lock. An assessor will therefore expect the organization to show how the display is configured, not only how the lock timer is set. Systems categorized at the low baseline select only the base control, so the enhancement is a concrete addition to scope for any moderate or high system.

The practical test is simple to describe and easy to get wrong. An assessor typically sits at the locked device or reviews configuration evidence and looks for residual content: open documents, email previews, dashboards, application windows or chat notifications still visible behind the lock screen. Shared spaces such as clinic desks, trading floors, control rooms and open-plan offices raise the stakes, because a locked screen that still shows sensitive data is effectively unlocked to anyone walking past. Screen capture and screen sharing deserve a separate check, since a locked session that remains streamed or recorded can expose the same content. Operating system and endpoint management settings for lock screen content, notification visibility and screen sharing are the places to look, and the exact mechanisms vary by platform, so confirm them against your own fleet.

Before relying on this summary, confirm the enhancement wording, its parameters and the baseline selection in the current NIST catalog and baseline profiles, not in this page. Ask your assessor which evidence they will accept for the display behavior, such as configuration exports, screenshots of a locked device taken under test conditions or endpoint policy reports. If you run a self-hosted fleet, a policy that checks screen lock and related settings across endpoints, such as the osquery-based approach described in Fleet's guide to policies, can show which devices pass or fail. Decide early which device types are in scope for moderate and high systems so the display check covers every endpoint that holds sensitive data.

How to implement device lock across the fleet

This sequence turns the AC-11 requirement into a fleet-wide setting that locks sessions on inactivity or user request, holds the lock until normal authentication, and produces records an assessor can test. It runs from the policy decision through configuration, the moderate and high enhancement, verification and recurring checks.

Set the inactivity period and lock rules
The organization defines the period of inactivity after which a session locks, and states that users may also lock their own sessions on request. Its access control policy and procedures record these values, along with the device types and user populations they cover. The output is an approved parameter with a named owner and an approval record, which assessors examine first for AC-11.
Write the configuration baseline
Engineering translates the approved parameter into a configuration baseline for each operating system image, mobile device profile and virtual desktop platform in the environment. The baseline names the setting, the expected value and the platform policy that enforces it. Confirm the exact setting names with each vendor's documentation, since they differ by platform. The output is a baseline document tied to the system security plan.
Deploy the lock settings to every device
Administrators push the baseline through the existing management tooling, such as directory group policy, mobile device management or configuration management. Deployment should cover managed endpoints, virtual desktop sessions and shared kiosks, since each can hold an unlocked session. Users should not be able to disable or lengthen the lock locally. The output is a deployment record showing which device groups received the policy and when.
Enable pattern-hiding for moderate and high systems
For systems categorized at the moderate or high baseline, enable the AC-11(1) display behavior so that the screen no longer shows the prior work while locked. Confirm the platform supports the behavior and document any device where it cannot be enforced, along with the compensating measure. The output is a per-system record of the enhancement status, which the system security plan should reflect.
Verify re-authentication uses normal identification
Test a locked session on a representative sample of each device type and confirm that unlocking requires the organization's standard identification and authentication path, such as the usual password, multifactor prompt or smart card. Record any path that accepts a weaker method. The output is a dated test record with the device, the tester and the result, which supports the test method in SP 800-53A.
Query lock status across the fleet
Use an endpoint query tool to confirm that the lock policy is present and applied on each device. Open-source options include Fleet, whose policies ask yes or no questions of devices as osquery queries and show which devices pass or fail each policy. Confirm the query coverage with the tool's current documentation before relying on it. The output is a policy pass or fail report per fleet.
Scan settings against the baseline
Run a configuration assessment against the baseline to detect drift. Wazuh's Security Configuration Assessment checks files, registry keys and running processes against YAML policies and can be extended with custom policies that encode the organization's lock values. Confirm the policy content matches the approved parameter. The output is a scan report with remediation recommendations for failing endpoints.
Schedule recurring checks and exceptions
Set a recurring review of the policy results, the test records and the exception register, and assign an owner for each failing device. Each review should note any change to the approved parameter and re-run the verification after platform updates. The output is a dated review log and an updated exception list, which feed the assessment evidence for AC-11 and the related controls AC-2, AC-7 and IA-11.

Evidence that passes an AC-11 assessment

An assessor testing AC-11 looks for a documented lock requirement, configuration that enforces it, and test records showing it works on real endpoints. The cards below group the artifacts that satisfy the examine, interview and test methods, and each one should have a named owner who refreshes it on a set schedule and whenever change control touches the affected systems.

Access control policy and session lock procedures

The policy states the organization-defined inactivity period, which user actions may trigger a manual lock, and how long the lock must hold until the user reauthenticates through normal identification and authentication. The session lock procedures name the roles that configure and verify the lock and the steps for handling exceptions. Assessors examine these documents first, so the inactivity value in the policy must match the value in the configuration. Owners should review both documents on the organization's policy cycle and after any change to identity or endpoint standards.

Configuration baselines with lock parameters

Keep a written baseline for each endpoint and server image that sets the inactivity timeout, the manual lock option and any policy that prevents users from disabling the lock. Store the baseline as code or as exported settings in version control, so assessors can see the value and its history. Compare each image against the baseline during build and after patch cycles. The baseline should be revalidated whenever an operating system or desktop environment upgrade changes the setting names or defaults.

Test records for inactivity and manual lock

Record a dated test on a representative sample of each device class showing that the session locks after the defined idle period and that a user-initiated lock works from the interface. Screenshots alone are weak evidence, so pair them with the test steps, the tester's name, the configuration value in force and the outcome. Repeat the test after major OS updates and whenever the baseline changes. Ask the assessor which sample size and device types they expect before testing begins.

Proof that the lock persists until authentication

Show that the locked session stays locked after the screen is left idle for longer than the timeout, after a network reconnect and after a reboot where the session is restored. Capture evidence that only normal identification and authentication, such as a password or an approved multi-factor method, releases the lock. Include a test where an incorrect credential is entered and the session remains locked. Retest after any change to the authentication stack, since a changed identity provider can alter how the lock releases.

Pattern-hiding display configuration for moderate and high systems

For systems in the moderate and high baselines, the AC-11(1) enhancement requires that the lock screen hide the previous screen content, so that no pattern or data remains visible. Document the setting for each device type, such as lock screen image, notification visibility and display of session content, and capture a screenshot of the locked display with sensitive data open beforehand. Confirm the behavior on external displays and on any mobile device class in scope. Note that this is a configuration evidence item, not a policy statement.

Fleet-wide compliance reports

A fleet-wide report shows which devices pass or fail the lock settings at a given time, and it is the artifact that proves the baseline applies to the whole population rather than the sample. Fleet policies written as yes or no osquery questions can check the presence of the setting on each device, and the policies page shows which devices in each fleet pass or fail. Export the results on a schedule, keep the dated exports, and record the remediation ticket for each failing device. Confirm with the assessor how far back they expect the reports to go.

What meeting AC-11 costs in money and effort

This table breaks down the cost components of meeting AC-11 Device lock, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for a quote: most of the cost sits in engineering and evidence upkeep, while license spend is the component open-source tooling can reduce. No figures are given because NIST does not estimate compliance costs and no fixed prices were supplied for this control.

Cost component	Who is paid or who spends	One-time or recurring	What drives it up or down
Defining the inactivity period and lock rules	Internal security and IT staff, or an implementation partner under a written scope	One-time, revisited on policy review	Number of device types, operating systems and the organization-defined inactivity period set per system category
Configuring device lock across device types	Platform or endpoint engineers	One-time per device class, then recurring on new builds	Device diversity, including managed laptops, shared kiosks, servers with consoles and mobile devices
Configuring the pattern-hiding display (AC-11(1))	Platform engineers and application owners	One-time, required only in moderate and high baselines	Number of applications and displays that show sensitive content when locked, and whether the baseline is moderate or high
Testing lock behavior and pattern-hiding display	Internal testers, or an external tester if bought	One-time, repeated after major OS or application changes	Number of device configurations tested and whether test results are captured as evidence
Endpoint management or compliance tooling licenses	Software vendor, through the organization's own procurement	Recurring, usually per device or per seat	Device count and whether an existing management platform already enforces the lock
Open-source tooling for lock checks	Engineering time to deploy and maintain, with no license fee for the software itself	One-time setup, recurring maintenance of checks	Fleet policies or Wazuh policies must be written and kept current for each OS version; the effort falls on staff, not on license spend
Ongoing evidence upkeep	Internal compliance and security staff	Recurring, each assessment cycle and after configuration changes	How often lock settings change, and whether passing and failing device reports are exported on a schedule
Auditor or assessor sampling effort	Independent assessor, paid by the organization under its own engagement	Recurring, per assessment	Number of systems and device groups sampled, and whether the organization can produce a clear list of devices with their lock settings

Open-source tools that produce device lock evidence

Two open-source tools can show whether lock settings are in place across your endpoints, which is the configuration half of AC-11 evidence. Neither one proves that the lock engages at the right time or that the display hides data, so they support the assessment rather than replace it.

Wazuh configuration assessment checks

Wazuh (GPL-2.0-only) Security Configuration Assessment scans monitored endpoints against YAML policies. Most shipped policies are based on CIS benchmarks, and you can add custom policies for your own standard. The checks cover files, directories, registry keys and running processes, and each failed check comes with remediation advice. For AC-11, confirm that the policy for each operating system checks the inactivity timeout and screen lock settings your organization defined. Confirm current policy content for your operating systems, because shipped policies change over time.

Wazuh custom policies for lock values

Where the shipped content does not match your defined inactivity period, write a custom YAML policy that checks the exact configuration value your standard requires. Keep the policy under version control with the access control procedures so the check and the requirement change together. Record which endpoints were scanned, when, and which policy version applied. An assessor can then compare the defined period in your documentation with the value the scan read on each endpoint.

Fleet policies for yes or no checks

Fleet (MIT) policies ask each device a yes or no question written as an osquery query, such as whether a screen lock setting is enabled with the required timeout. The policies page shows which devices in each fleet pass or fail. This gives you a current, per-device view that is easy to export as evidence. Write each policy to match one requirement in your AC-11 procedure, and record the query text with the date of the results.

Gaps the scans cannot prove

A configuration check reads the setting, but it does not show that the device actually locks after the period, that the lock holds until the user authenticates again, or that the display hides information as pattern-hiding under AC-11(1) requires. Test those behaviors on sample devices and record the results. Pattern hiding in particular is a display property that a settings query may not reveal, so plan a manual or mechanism test for moderate and high baselines.

License and operating model checks

Wazuh is licensed under GPL-2.0-only and Fleet under MIT, and both licenses should be reviewed by your legal team before you deploy them into your environment, especially if you modify the code or distribute agents. Confirm who runs the manager or server, where endpoint data is stored, and who reviews the failing results. Assessors look for an owner and a review cadence, not only the tool output.

Who does what for device lock: your team, a partner and the auditor

Your organization owns AC-11 in full. The control is a statement of how your systems behave when a user steps away, and it is your policy, your inactivity parameter and your risk decision that the assessor will examine first. No partner or auditor can make those choices for you, and the SP 800-53A assessment procedures start from documents your team must write and approve.

Policy ownership: Write and approve the session lock requirement, and assign who maintains it and how often it is reviewed.
Inactivity parameter: Set the organization-defined period of inactivity and decide whether it differs by device type, data sensitivity or user role.
Pattern-hiding decision: Decide whether the AC-11(1) display enhancement applies to your moderate or high systems and document the reason.
Exception handling: Approve and record any devices that cannot lock, such as kiosks or shared clinical terminals, with compensating measures.
Ownership of the security plan: Keep the system security plan describing the lock setting and the people accountable for it.

Before engaging anyone, confirm that your policy names the inactivity parameter in writing, because a partner can only configure what you have decided.

Where organizations usually fall short on device lock

Most device lock gaps are not missing policy. They sit in the distance between what the policy says and what each device actually does, how the lock behaves in edge cases, and whether the evidence still reflects the current estate. The cards below cover the gaps assessors most often find and the action that closes each one.

Timeout defined but not enforced everywhere

The policy sets an inactivity period, but the setting exists only on Windows domain-joined laptops. macOS, Linux workstations and kiosk devices often run with a default or no timeout. Build an inventory of every device class, confirm the inactivity lock on each one, and record the setting value and the method used to enforce it, such as a configuration profile, a desktop policy or an image baseline. Use Wazuh Security Configuration Assessment policies to check the setting on each endpoint and flag the ones that drift.

No lock on user request

Many systems lock after inactivity but give the user no quick way to lock on demand. AC-11 requires both triggers, so a user who steps away from a shared workstation must be able to lock it immediately. Confirm that each operating system and each remote desktop or virtual desktop client exposes a lock action, document the shortcut or menu path in the user guidance, and test it during the assessment walkthrough.

Lock that does not hold

A session can appear locked yet resume without a fresh login after the screen wakes from sleep, after a lid closes and reopens, or after a remote session reconnects to an already unlocked desktop. The lock must hold until the user re-authenticates through normal identification and authentication. Test wake from sleep, resume from hibernation and reconnection of remote sessions on each device class, and record the results as test evidence.

No pattern-hiding for moderate and high systems

The AC-11(1) enhancement applies in the moderate and high baselines and requires that the display conceal information previously visible while the device is locked. Without it, a locked screen can still reveal open documents, chat previews or dashboard data. Set the lock screen to hide prior content, such as a blank or generic image, and check it on every screen type in scope, including secondary monitors and kiosk displays.

Evidence collected once and never refreshed

Screenshots and a single configuration export from the last audit do not show that devices still lock today. Changes to images, management profiles and operating system releases can silently reset the timeout. Schedule recurring compliance scans, keep dated exports of the scan results and tie each refresh to change control, so the evidence an assessor sees matches the current estate. Ask the auditor which evidence age they accept before the engagement starts.

Shared and service devices excluded without a decision

Kiosks, shared clinic terminals, conference room systems, digital signage and service accounts on servers are often left out of scope with no record of why. Assessors will ask for the decision. For each excluded device, document the reason, the compensating control, such as a physical access restriction or a session that ends automatically, and the owner who accepted the risk. Fleet policies can ask yes or no questions of each device, such as whether an inactivity lock is set, and show which devices pass or fail, so exclusions and failing devices are both visible.

Common questions about AC-11 device lock cost, effort and assessment

How much effort does AC-11 device lock take, and what drives it?

The effort depends mostly on how many device types and user populations the system covers, and on whether the lock behavior is already enforced centrally. AC-11 asks for two things: a lock after an organization-defined period of inactivity or on user request, and a lock that stays in place until the user authenticates again. Where operating system policy, directory settings and mobile management already enforce both, the work is largely verification and documentation. Effort rises when endpoints are unmanaged, when shared workstations or kiosks need different timeouts, or when the moderate and high baselines require the pattern-hiding display enhancement, AC-11(1), on every screen that could show sensitive data. Ask any provider to break its quote down by device class, by baseline and by documentation work.

Can we implement AC-11 in-house without outside help?

Yes, many organizations implement it in-house, provided they own the configuration and can show the evidence. The control is mostly a matter of setting an inactivity timeout, a user-initiated lock and re-authentication requirement, then documenting the organization-defined period in the system security plan. Internal teams usually need someone who can configure the directory, endpoint management and operating system policies consistently, and someone who can test them. Outside help is most useful when the environment is large, spans several platforms or must be assessed for a contract or authorization. Whatever the choice, the organization owns the control and its decisions.

How long does preparing AC-11 take, and what does it need from our team?

Preparation time depends on the state of your current configuration, not on the control text alone. Your team needs to decide the inactivity period for each system category, confirm which platforms enforce it, collect the policy settings and record exceptions with approvals. Platform owners must test that the lock appears and that re-authentication is required, and the system security plan must describe the mechanism. Ask any implementation partner for a written schedule tied to a defined scope, including which systems are in it and who approves the organization-defined values. DeployOpen plans and prepares these systems under a fixed-scope written agreement, but the organization sets the parameters.

Are open-source tools enough to produce AC-11 evidence?

Open-source tools can produce useful evidence, but they show configuration state rather than complete control operation. Wazuh's Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom checks, and reports files, registry keys and processes with remediation advice. Fleet policies are yes or no osquery questions, and its policies page shows which devices pass or fail each policy. Together they can show that a lock timeout is set on most endpoints and flag drift. They do not prove that a lock occurs in practice on every device, so confirm the lock behavior with test records and the configuration of any device outside management coverage.

What will an assessor sample when testing AC-11?

An assessor following the SP 800-53A procedure for AC-11 examines the access control policy, procedures addressing session lock, identification and authentication procedures, system design documentation, configuration settings and the security plan. They interview system and network administrators and system developers, and they test the mechanisms that implement session lock. In practice, expect requests for the configured timeout values, the policy objects that apply them, a sample of devices or user groups with their settings, and a demonstration that a lock occurs and requires re-authentication. Prepare a sample that covers each device class and each baseline, and keep the records for any exception.

Can a consultant issue the AC-11 assessment result?

No. A consultant or implementation partner can prepare systems, configurations and evidence, but only an independent assessor or the authorizing body issues the assessment result. The organization owns its controls and decides the risk. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports, attestations or certifications. When a contract or authorization requires a formal result, ask who the independent assessor will be, how their independence is ensured, and what they will deliver in writing before the engagement starts.

Does AC-11 map to NIST CSF 2.0?

Not through NIST's own crosswalk. NIST's OLIR crosswalk from CSF 2.0 to SP 800-53 Release 5.2.0, posted 17 November 2025, does not list AC-11 against any CSF 2.0 subcategory, and NIST marks the crosswalk as not comprehensive. That means you should not assume a CSF subcategory is satisfied by AC-11 alone. If you use CSF 2.0 for reporting, map your own evidence to the subcategories your program uses, document the reasoning, and confirm the approach with your assessor or governance team.

How DeployOpen scopes and prepares device lock evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so device lock settings and their evidence can be prepared where the systems actually run. The organization keeps ownership of its controls, and an independent assessor decides whether AC-11 is met.

How we scope

Agree in writing which systems, endpoints and user populations fall under the AC-11 session lock requirement.
Record which inactivity period the organization has defined and where that value is set for each platform.
Confirm with the client whether the moderate and high baseline pattern-hiding enhancement AC-11(1) applies to the system.

How we build

Configure the session lock and re-authentication settings on the self-hosted platforms within the agreed scope.
Apply pattern-hiding display settings where the client's impact level requires AC-11(1) and document the configuration.
Deploy open-source configuration assessment checks, such as Wazuh policies or Fleet queries, to show whether lock settings persist on endpoints.

How we hand over

Deliver configuration records, check results and the procedure documents that an assessor examines for AC-11.
Document test steps the client's staff can repeat to show a lock occurs after inactivity and on user request.
Provide a written handover that maps each artifact to the AC-11 determination statements for the client's assessor.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing of lock settings are available as a retainer.
Confirm with your assessor which evidence formats they accept before the engagement begins, since assessors issue any findings.