Safeguard 2.6 allowlist authorized libraries

What Safeguard 2.6 asks for when allowlisting libraries

Safeguard 2.6 asks you to extend application allowlisting from executables to the libraries those executables load. In practice, technical controls should allow only approved library files, such as the .dll, .ocx and .so examples CIS gives, to load into a system process, and should stop unapproved ones. The Safeguard also expects the control to be reassessed at least twice a year. If you have been told to extend your allowlisting beyond executables, the first decision is scope: which processes, hosts and library types are in the enforcement boundary, and who approves additions to the list.

The risk is straightforward. A malicious or unvetted library does not need to run as its own program. If it is loaded into a trusted process such as a browser, a database service or a管理 tool, it inherits that process's permissions, network access and reputation with security tooling. Attackers use this kind of injection because an executable allowlist alone often reports a clean picture while a rogue library sits inside an approved binary. Libraries also change more often than executables, through patches, plug-ins and vendor updates, so a list that was accurate at go-live can drift quickly.

The work is hard for two reasons. First, a typical host loads many more library files than it runs programs, so the approved list is large and needs an owner who can judge vendor updates. Second, Safeguard 2.6 sits in Implementation Groups 2 and 3 rather than IG1, so organizations with less operational complexity usually defer it. Before you commit to a rollout, confirm with your endpoint and security vendors whether their enforcement tools can block library loads in your target operating systems, and ask your team how many library files your critical processes load today. Those two answers will shape the cost and timeline more than any other factor.

Which libraries, systems and teams fall under Safeguard 2.6

Safeguard 2.6 applies only at IG2 and IG3, and its work is set by a few scoping decisions: which system processes load libraries, which library types count, who maintains the approved list and how vendor code gets through. Each card below is one decision to settle before the measurement starts.

Implementation Group applicability

Safeguard 2.6 is assigned to IG2 and IG3 and not to IG1, so an IG1 enterprise is not expected to meet it. Confirm your Implementation Group against the CIS Implementation Groups pages before committing budget, and record the decision in your scope statement. If your organization is moving from IG1 to IG2, library allowlisting is one of the Safeguards that the step adds.

In-scope enterprise assets and processes

Start with the enterprise assets where libraries load into privileged or sensitive processes, such as domain controllers, payment or identity servers, and endpoints used by administrators. Then list the processes that load those libraries, because the control is about what loads into a system process, not about files sitting on disk. Document exclusions with a reason, for example a development build host that never handles production data.

Library types and file formats

CIS gives .dll, .ocx and .so as examples, so your scope should name the formats present in your estate, including any Java archives, Python extension modules or macOS dynamic libraries that your processes load. Run the software inventory from Safeguard 2.1 against the processes to find which libraries are actually in use. A format left out of the scope is a format that can load without a check.

Owners of the approved library list

Assign one accountable owner for the approved library list, with named maintainers from platform engineering and application teams who can request additions. Security should approve changes and operations should record them. Without a named owner, the list drifts, and the twice-yearly reassessment has no baseline to compare against. Confirm the approval path in writing with each team that deploys software.

Vendor and third-party library exceptions

Vendor agents, runtime components and open-source dependencies often load libraries that no internal team wrote or reviews. Define an exception path with a documented business reason, a named risk owner, a review date and any compensating controls. Ask each vendor which libraries its product loads and which versions it requires, because an exception that cannot be described cannot be measured in the assessment.

Prerequisite data from Safeguards 2.1, 2.5 and 4.2

The CIS Controls Assessment Specification lists Safeguards 2.1 (software inventory), 2.5 (software allowlisting) and 4.2 (network infrastructure secure configuration process) as prerequisites because they usually produce the data the measurement needs. Confirm each one exists and covers the in-scope assets before you start Safeguard 2.6, since a gap in the inventory becomes a gap in the library list. Mappings to other frameworks, including NIST SP 800-53 CM-7 and CM-7(1), ISO/IEC 27001:2022 Annex A 8.19, SOC 2 CC5.2 and PCI DSS v4.0 requirements 1.2.5 and 2.2.4, should be confirmed against the current CIS Controls Navigator before audit scoping.

How an assessor tests library allowlisting

This table compares each assessment element the CIS Controls Assessment Specification uses for Safeguard 2.6 with the evidence an assessor requests and the findings that commonly appear. Read it as a checklist of what the measured result must show, since the assessor tests whether library loading is actually controlled, not whether a policy exists.

Assessment element	What the assessor checks	Evidence requested	Common finding
Reassessment currency	Whether the Safeguard was last assessed within six months. The specification scores it as failing when the last assessment is older than that.	Dated reassessment records for the library allowlist, signed off by the owner	A reassessment record that is older than six months or undated
Allowlist configuration coverage	The share of allowlisting software that is properly configured to restrict which library files load into system processes	Configuration exports from the allowlisting tool and the list of endpoints it manages	Some endpoints or processes run without the library rule set applied
Approved library list	Whether the approved library list names the files (for example .dll, .ocx or .so) that the organization permits to load	Versioned library list with owner, approval date and justification for each entry	Libraries present on endpoints that do not appear on the approved list
Prerequisite: software inventory (2.1)	Whether library files can be traced back to software records that the inventory identifies	Inventory extract mapping software to its libraries and installation locations	Library paths that cannot be matched to any inventoried software
Prerequisite: software allowlisting (2.5)	Whether the application allowlisting that underpins library control is in place and reviewed	Application allowlist policy, enforcement settings and its own reassessment record	Library control described as in place but the 2.5 allowlist was never reviewed
Prerequisite: network secure configuration (4.2)	Whether the documented configuration process governs how allowlist settings are deployed and changed	Secure configuration process document and change records for allowlist rules	Allowlist changes made by hand with no recorded approval or baseline
Sampled endpoints	Whether the assessor's sample of endpoints shows the same library behavior as the exported configuration	Live or recent endpoint reports for the sampled systems, plus the sampling method used	Sampled endpoint loads an unapproved library that the export did not show

How to implement library allowlisting in sequence

This sequence moves Safeguard 2.6 from an inventory of libraries to an enforced allowlist that blocks unapproved libraries from loading into system processes, with dated records that show it is reassessed at least twice a year. Each step produces an artifact that the next step depends on, so an assessor can trace the control from the first list to the latest review.

Build the library inventory from the software inventory
Start from the software inventory maintained under Safeguard 2.1 and identify every library file that loads into system processes on in-scope assets, including .dll, .ocx and .so files. Your platform team or endpoint administrators should collect these from the operating system and from the applications that ship them, then record the file name, version, hash, publisher and the software that depends on it. The step is complete when each in-scope asset has a library list that ties back to a named software entry, and someone who owns the asset has reviewed it.
Decide the approved library set per process
Group the inventory by system process and by asset role, then decide which libraries each process is authorized to load. Involve application owners, because they know which libraries are required for business function and which are leftovers. Record the decision, the approver and the reason for each entry, so that a future reviewer can see why a library was allowed. The output is a written approved library set for each process class, reviewed and signed off by the accountable owner.
Run the allowlist in monitor-only mode
Deploy the library allowlist in a mode that logs and reports attempted loads of unapproved libraries without blocking them. Run it long enough to observe normal patching, updates and application start-up cycles, and review the logs for legitimate libraries that the approved set missed. Update the approved set for each confirmed legitimate library and record the change. The step is complete when the monitor-only logs show no unexplained unapproved loads that would have broken a business process, and each entry has a documented disposition.
Switch to enforcement with a documented exception path
Move the allowlist from monitoring to blocking on the assets and processes you have validated, in stages that let you roll back a single policy if it disrupts operations. Define a documented exception path that states who can approve a temporary library exception, what compensating controls apply, and when the exception expires. Confirm with your allowlisting platform vendor which enforcement modes, process scoping and library-level controls it supports, because capability differs by product. The output is an enforced policy set, a tested rollback procedure and an exception register.
Verify enforcement and measure the outcome
Test the enforced allowlist with known approved and unapproved libraries on representative assets to confirm that blocking works as the policy describes. Record the results, including any gaps, and feed them back into the inventory and approved set. If you use a configuration assessment or endpoint query tool, use it to report which assets are passing or failing the library policy, so the state of the control is visible without manual checks. The output is a dated verification record for each policy and asset group.
Set the twice-yearly reassessment with dated records
Schedule a reassessment of the library allowlist at least twice a year, covering the approved set, the exception register, enforcement coverage and the software inventory it depends on. Each review should record the date, the reviewer, the assets assessed, the changes made and any exceptions closed or extended. Keep the records with the control evidence so that an assessor can see the review cycle over time. The output is a dated review record that shows the last assessment date is within the required interval.

Evidence that shows library allowlisting is working

Assessors looking at Safeguard 2.6 want to see a documented list of approved libraries, enforcement that is actually configured on each system, records of what was blocked, and a dated reassessment. The cards below connect those artifacts, and each one should be exported or dated on a schedule so the evidence is current when the reassessment falls due.

Approved library list with owners

This is the register of library files (for example .dll, .ocx and .so files) approved to load into system processes, with each entry's owner, the approving person and the approval date. It is the baseline every other artifact is compared against. Check that each entry links to the software it belongs to and that entries are removed when a product is retired. Export the list on a schedule and store dated copies so you can show what was approved at any past assessment date.

Enforcement configuration per system process

Export the allowlisting policy or configuration that applies to each system process, showing which libraries each process may load and what happens to anything else. Assessors will check that the policy matches the approved list and that it covers the processes you say it covers. Confirm with your tooling vendor how the export is produced and whether it can be captured without manual editing. Keep dated exports after every change.

Blocked and allowed library load logs

Logs of library loads show whether enforcement is operating in practice, not only on paper. Review records of blocked loads for unapproved libraries and confirm that each block was investigated or matched to a known change. Record allowed loads of new libraries as well, since they reveal approval gaps. Confirm that the log source retains records for the period your assessor will sample, and that the logs are protected from modification.

Reassessment record with last result

Safeguard 2.6 expects the allowlisting to be reassessed at least twice a year. Keep a dated reassessment log that shows when each review happened, who performed it, which systems and libraries were checked and the result. The CIS assessment specification treats a Safeguard last assessed more than six months earlier as failing, so the log must show the most recent review date at all times. Schedule the next review in your calendar or ticketing system before closing each one.

Exception records with compensating controls

Some systems cannot enforce library allowlisting, for example because a vendor product needs to load unapproved components. Each exception should name the system, the libraries involved, the compensating controls such as monitoring or network isolation, the accepted residual risk and the approver. Review exceptions at each reassessment and close those that are no longer needed. Assessors will look for exceptions that were recorded and reviewed, not for an absence of exceptions.

Link to the software inventory

Safeguard 2.1 software inventory is the prerequisite for measuring Safeguard 2.6, because it tells you which systems exist, which software runs on them and therefore which libraries need approval. Show a traceable link from each system in the inventory to its allowlisting policy and its latest enforcement log. Check monthly that new hosts appear in the inventory before they receive a library policy, and keep the inventory export in the same evidence set as the reassessment log.

Open-source tools that can support library allowlisting evidence

Wazuh's Security Configuration Assessment (SCA) module scans monitored endpoints for misconfigurations using YAML policies. Most shipped policies are based on CIS Benchmarks, and organizations can write custom policies for their own requirements. SCA checks files, directories, registry keys and running processes, and it recommends remediation for failed checks. Wazuh is licensed under GPL-2.0-only. For Safeguard 2.6, that means it can show whether specific library files exist, where they sit and what is running, which is useful input when reviewing whether unapproved libraries are present.

Custom policies: Write YAML checks that look for the approved library paths and file attributes your allowlist defines.
Process and file checks: Use SCA to show which processes are running and whether listed files are present in expected locations.
Scan results over time: Retained scan output gives the reassessment record dated pass and fail results per endpoint.
Enforcement gap: Wazuh does not by itself enforce library allowlisting. Confirm with the vendor documentation whether any blocking capability applies in your deployment before you describe it as preventive.
Scope limits: Check coverage on each operating system and endpoint class, since a policy that does not run on a host produces no evidence for it.

Before relying on Wazuh output, confirm which of your allowlist controls it can check and whether its policies match the library rules you actually approved.

What meeting Safeguard 2.6 costs in money and effort

This table breaks down the cost components of meeting Safeguard 2.6, who is paid for each one, whether it is one-time or recurring, and what drives it up. Use it to build a quote request or to check a vendor or partner proposal line by line. No price is stated here because the figures depend on the written scope of your environment.

Cost component	One-time or recurring	What drives it up	What to ask for in a written quote
Enforcement tooling or licenses	Recurring where commercial; zero license spend is possible with a self-hosted open-source option	Number of endpoints and server types, OS mix, need for vendor support contracts	Confirm in writing that the tool can restrict which library files load into a named process, and whether that capability is in the free edition
Library inventory and baseline	One-time, then refreshed at each review	Count of .dll, .ocx and .so files, number of system processes, third-party and vendor-supplied software	Method for collecting library data, a sample inventory report, and who approves the initial approved list
Engineering time for rollout	One-time per platform, plus changes as systems are added	Heterogeneous estates, legacy applications, number of distinct system processes that load libraries	Phased rollout plan, which processes are covered first, and rollback steps for each stage
Test and exception handling	Recurring as software and patches change	Frequency of vendor updates, custom internal libraries, number of documented exceptions	Test environment scope, exception request workflow, and the approval record kept for each exception
Evidence upkeep	Recurring	Number of systems in scope, change frequency, depth of configuration history retained	Evidence list mapped to the Safeguard's assessment measures, retention period and storage location
Twice-yearly reassessment labor	Recurring, at least every six months	Scope size, number of reviewers, whether the review is automated or manual	Reassessment checklist, dated record of each review, and the reviewer's sign-off
External testing and auditor sampling	Recurring at each assessment cycle	Assessor sample size, number of in-scope systems, need for independent testing of allowlist bypass	Scope and sample basis agreed with the assessor before fieldwork, and whether testing is included or quoted separately

Where library allowlisting programs usually fall short

Library allowlisting under Safeguard 2.6 rarely fails in one dramatic place. It usually weakens quietly: reviews lapse, enforcement stays in monitoring mode, and the lists underneath it were never built from a verified inventory. The cards below cover the gaps assessors most often find and the checks that close each one.

Reassessment record lapses

The CIS Controls Assessment Specification scores Safeguard 2.6 as failing when the Safeguard was last assessed more than six months ago, so the reassessment is a pass or fail condition, not a best effort. Keep a dated record of each review, who performed it and what changed in the library list. Check the record against the calendar before the assessor does, and set a reminder well inside the six-month window. Also confirm that the reassessment covers the approved library list itself, not only the tooling that enforces it.

Enforcement stuck in audit mode

Many teams deploy library allowlisting in a logging or audit-only mode and never move to enforcement. Safeguard 2.6 asks that unapproved libraries be stopped from loading into system processes, so a log of blocked-in-theory events does not satisfy it. Ask for the enforcement state of each endpoint group, the date each group moved from audit to enforce, and the list of exceptions that still run in audit mode. Any group still in audit mode needs a documented reason and an end date.

Library list built without inventory

A library allowlist drawn up from memory or from a single build image misses libraries that arrive with applications, updates and plug-ins. Safeguard 2.1 software inventory is a prerequisite because it shows which applications exist on each asset and therefore which libraries they load. Compare the library list against the software inventory for the same asset population. Libraries with no owning application in the inventory are a signal that the list or the inventory is incomplete.

Exceptions without owners or dates

Business applications often need a library that is not yet approved, and those requests become permanent exceptions with no named owner and no review date. An exception without an owner cannot be closed, and one without a review date drifts out of the twice-yearly cycle. For each exception, record the business justification, the accountable owner, the compensating control and the date it will be reviewed or removed. Expired exceptions should appear in the reassessment as open findings.

Vendor libraries never reviewed

Libraries bundled by commercial software vendors are often approved once at installation and then updated silently by the vendor. A new version can change the file set that loads into a process, and the allowlist then holds an outdated or unapproved file. Ask each vendor which libraries its product loads, how updates are delivered and how the approved list will be refreshed after each update. Treat a vendor update that adds a library as a change that triggers review.

Prerequisites that produce no data

Safeguards 2.1, 2.5 and 4.2 are listed as prerequisites because they generate the data that the Safeguard 2.6 measurement needs. A written inventory process, an allowlisting policy and a secure configuration procedure that nobody runs will not yield measurable results. For each prerequisite, confirm that it produces a current, queryable output, such as an inventory export, an allowlist configuration state or a configuration baseline with a last-run date. If the output does not exist, the Safeguard 2.6 measurement has nothing to test.

Who does what: your team, an implementation partner and the auditor

Your organization owns the control. Someone accountable must decide which library files may load into system processes, why each one is trusted, and who approves an exception when a business application needs a library that is not on the list. These decisions cannot be delegated to a vendor or a consultant without losing the accountability the Safeguard expects. Your team also decides the risk tolerance for libraries that cannot be allowlisted, such as legacy components with no vendor support.

Approved library list: Maintain the list of authorized library files, including name, version, hash, publisher and the owning application.
Risk decisions: Record why each library is trusted and what residual risk remains for those that are not.
Exception approvals: Approve, time-bound and review every exception, with a named owner and mitigating controls.
Reassessment cadence: Schedule and sign off the reassessment at least twice a year, and keep the minutes.
Change control: Route library additions and removals through the same approval process used for other production changes.

Check that the person signing exceptions has authority over the affected systems and that the approved list matches what your inventory from Safeguard 2.1 actually shows.

Questions buyers ask about Safeguard 2.6

Does Safeguard 2.6 apply to IG1 organizations?

No. CIS assigns Safeguard 2.6 to Implementation Group 2 and Implementation Group 3, not to IG1. IG1 is CIS's essential cyber hygiene baseline, and its software Safeguards focus on knowing what runs in the enterprise and removing what should not. If your organization is IG1 and a customer or regulator asks for library control, you can still adopt it voluntarily, but it is not part of the IG1 minimum. For IG2 and IG3 enterprises, the work depends on Safeguard 2.5 software allowlisting already working, because the CIS Controls Assessment Specification lists Safeguards 2.1, 2.5 and 4.2 as prerequisites for measuring 2.6. Confirm your Implementation Group against the CIS Implementation Groups page before you scope the work.

What does Safeguard 2.6 implementation cost and what drives it?

The cost depends on the size of the estate, the number of library types in use and how much prerequisite work is already done. No researched figure is available for this, so ask for a fixed-scope quote built from your own environment. The main cost components are internal staff time for library list owners and administrators, engineering time to build and test policies, and any implementation partner fees, which are set by the scope agreed in writing before work starts.

One-time costs: discovery of libraries loaded by critical processes, policy design, pilot testing and documentation.
Recurring costs: the reassessment at least twice a year, library approvals as software changes, and ongoing monitoring.

Costs rise with many vendors, legacy applications with unknown dependencies, mixed operating systems and a weak software inventory. They fall when Safeguards 2.1 and 2.5 already produce reliable data. Ask for separate line items for discovery, policy build, rollout waves, the evidence pack and reassessment support.

How long does it take to pass a Safeguard 2.6 reassessment?

The timeline depends on your prerequisites and your change calendar, and no fixed period is published for it. The CIS Controls Assessment Specification scores Safeguard 2.6 as failing when it was last assessed more than six months ago, so the schedule must keep every assessment inside that window. The main drivers are whether Safeguards 2.1 and 2.5 already produce usable data, how many libraries and processes must be covered, how many change windows you can use for staged enforcement and how quickly exceptions are approved. A common pattern is a baseline assessment first, followed by enforcement in waves on non-critical systems. Ask any partner for a written plan with milestones and the date of the next reassessment, and check it against your own change calendar before committing.

Can our own team implement Safeguard 2.6 without outside help?

Yes, if your team already runs software inventory and application allowlisting and has engineers who can test library loading without breaking production. Most of the work is process and testing: deciding which libraries are approved, building policies, piloting on non-critical systems and producing evidence that repeats every six months. Teams without these skills often underestimate dependency mapping, because one unlisted library can stop a business application from starting. An outside partner can prepare systems and evidence under a fixed-scope agreement, but the organization still owns the control, its decisions and its approvals. Independent assessors perform any formal testing. Decide between internal and external delivery by comparing your staff time and experience with the written scope.

What do we need from our team for library allowlisting?

Three groups must commit time: owners of the approved library list, system administrators with access to target endpoints and servers, and change managers who can schedule windows. Library list owners decide which .dll, .ocx and .so files each application and process may load, record the reason for each approval and review it when software changes. Administrators provide access for discovery, then configure enforcement and rollback on each platform. Change managers approve staged rollouts so enforcement does not interrupt business services. You also need a current application inventory, a named owner for each business system and a fast exception path with an expiry date. Without named owners, exceptions accumulate and enforcement is often relaxed to keep systems running. Confirm names, hours and change windows before work begins.

Does CIS certify that our organization complies with Safeguard 2.6?

No. CIS publishes the Controls and the Assessment Specification, but it does not certify organizations against them. An assessor tests your implementation against the Assessment Specification's inputs, operations, measures and metrics for Safeguard 2.6, and the organization owns the result and the evidence behind it. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme. If a customer or regulator asks for proof, agree in writing on the assessor, the scope and the evidence format before testing begins. CIS Controls Accreditation applies to CIS SecureSuite member organizations that provide implementation, auditing or assessment services, which is a separate matter from certifying your enterprise. DeployOpen prepares systems and evidence for assessment but does not issue reports or certificates; independent assessors do.

What evidence should we keep to show Safeguard 2.6 is working?

Keep dated, repeatable records that show the approved library list, the enforcement state of each system and the most recent assessment. Typical evidence includes:

The approved library list for each application, with owner, reason and review date
Configuration exports showing allowlist enforcement on each in-scope endpoint or server
Logs or reports of blocked library loads and the exceptions raised for them
Records of the latest assessment and the next due date, kept within the six-month window

Open-source tools can help produce some of this. Fleet policies, for example, are yes or no questions written as osquery queries, and the policies page shows which devices pass or fail each one. Confirm with your assessor which artifacts they accept, because the Assessment Specification defines what to measure, not how you must collect it. Fleet policies guide

How DeployOpen scopes and prepares library allowlisting evidence

DeployOpen plans and implements the technical side of Safeguard 2.6 Allowlist authorized libraries inside your own infrastructure, so that approved library files are the only ones allowed to load into system processes. We prepare the systems, configuration and evidence that an assessor reviews, while your organization keeps ownership of its controls and the independent assessor issues any conclusion about them.

How we scope

The written scope names which endpoints, servers and platforms are in library allowlisting scope for Safeguard 2.6.
Scope records the prerequisite inputs from Safeguards 2.1, 2.5 and 4.2 that the measurement depends on.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

How we build

We configure library allowlisting policies for approved .dll, .ocx and .so files on the agreed system types.
We test that unapproved libraries are blocked from loading into system processes, and record the results.
We wire the allowlisting configuration to the baseline checks in your existing security configuration process.

How we hand over

We document the approved library list, its owner, and the process for adding or removing entries.
We deliver the configuration files, test records and compliance check output that show the control is in place.
We map each evidence item to the twice-yearly reassessment so your team can repeat the review on schedule.

How we support

We can run the scheduled reassessment of library allowlisting under a retainer, if your organization wants that help.
We update policies when new approved libraries are added, and re-test after platform upgrades.
Your assessor reviews the evidence independently, and we confirm with your team which evidence the assessor will request.