Safeguard 4.5 end-user device firewall: requirements and evidence

What Safeguard 4.5 asks for and why default-deny matters on laptops and desktops

Safeguard 4.5 asks for something stricter than having a firewall switched on. Each end-user device, meaning laptops and desktops, should run a host-based firewall or port filter that blocks all traffic by default and lets through only the services and ports someone has explicitly permitted. Safeguard 4.4 covers firewalls on servers, and a server firewall that merely logs or allows broad ranges can satisfy 4.4 in part. Safeguard 4.5 closes that gap for the devices people carry out of the office and use on untrusted networks. In CIS Controls v8.1 it sits in the Devices asset class and the Protect security function, and it is assigned to all three Implementation Groups, so it is part of the IG1 essential cyber hygiene baseline that every enterprise is expected to meet.

The risk is concrete. A roaming laptop joins hotel, home and client networks, and any service listening on it, such as file sharing, remote desktop or a developer server left running, becomes reachable by other hosts on that network. If an attacker compromises one device, a permissive host firewall lets them move sideways to neighboring machines or reach services they should never see. Default-deny limits both the inbound exposure and the paths an intruder can use after a foothold. Hardening is hard for three reasons: fleets mix Windows, macOS and Linux with different firewall tools, business applications need exceptions that drift over time, and some devices are unmanaged, so no central policy reaches them at all.

Start by asking for the current rule set on a sample of each OS image and comparing it with a written list of permitted services and ports, with a named owner for every exception. Confirm with your endpoint management vendor and your own environment which firewall tool each platform uses and whether the default inbound action can be enforced and reported centrally. Devices that fail that check belong on a remediation list, and any device you cannot verify is a gap to record, not a pass to assume.

Which devices, teams and exceptions fall inside Safeguard 4.5

Scope for Safeguard 4.5 starts with the enterprise asset inventory and the software inventory, then decides which devices, owners and exceptions the deny-by-default firewall rule must cover. Each card below is one decision the organization owns and should document before it asks an assessor to measure coverage.

End-user endpoints in the asset inventory

Start from the enterprise asset inventory that Safeguard 1.1 produces. Every laptop and desktop listed there as an end-user device is a candidate for the host firewall requirement, so the inventory is the population the coverage measure is calculated against. Check that the inventory records the operating system and device owner for each endpoint, because those fields decide which firewall method applies. Devices missing from the inventory cannot be measured, so confirm the inventory is current before you set the denominator.

Built-in operating system firewalls

Decide which firewall each operating system uses to meet the requirement. Most desktop operating systems ship with a host firewall, but the default posture is often allow-inbound with exceptions, which does not meet a deny-by-default expectation. Record the product, the version and the policy source for each operating system family, and confirm that the policy is set centrally where the platform allows it. Where a built-in firewall cannot enforce default deny, document the compensating port filter or agent.

BYOD and contractor devices

Decide whether personal devices and contractor laptops that access enterprise systems count as end-user devices in scope. If they connect to enterprise resources, the organization needs either a managed firewall policy on them or a documented access restriction that limits what they can reach. Ask whether the access control layer can enforce the posture before granting access. Record the decision in the scope statement so that assessors do not find an unmanaged population without an explanation.

Remote and home-office workers

Remote workers use networks the organization does not control, so the host firewall is often the only enforced boundary on the device. Confirm that the firewall policy applies whether the device sits on the corporate network, a home network or a public Wi-Fi network, and that it does not depend on a VPN being connected. Check how policy reaches devices that rarely connect to the office, and how a device that has not checked in is treated.

Business-critical service exceptions

Some end-user devices run instrument software, clinical applications or trading tools that need inbound ports that a default-deny policy would block. Each exception should name the service, the port, the protocol, the device group, the business owner and a review date. Keep exceptions as narrow as the service allows, and record why a broader rule was refused. Undocumented exceptions are the most common reason a deny-by-default claim fails review.

Prerequisite inventories and the secure configuration process

The CIS Controls Assessment Specification lists the software inventory (Safeguard 2.1) and the secure configuration process (Safeguard 4.1) as prerequisites for measuring Safeguard 4.5. The software inventory shows which services and listening applications exist on each device, and the documented process sets the firewall baseline and who approves changes. Confirm both exist and are current before you collect firewall evidence, since the measures depend on them.

How an assessor tests the end-user device firewall

This table walks through how an assessor works through Safeguard 4.5, from sampling devices against the inventory to reviewing exceptions, and what each step produces. Read it as a checklist of what to have ready before an assessment, since the same steps show where gaps usually appear. The main takeaway is that coverage is measured against the inventory, so devices missing from it count against the result.

Assessment step	What the assessor checks	Evidence usually requested
Measure 1: Enablement	Whether the host firewall or port filter is switched on for each sampled end-user device	Configuration or management console export showing firewall state per device and the date it was taken
Measure 2: Default deny	Whether inbound and outbound traffic is blocked unless a rule explicitly permits it	Exported firewall policy showing a default block action and the rule set in force
Measure 3: Allowlist	Whether the permitted services and ports match a documented, approved list for the device role	Approved allowlist by device group, plus the rules that implement it
Sampling from the inventory	Whether the sample is drawn from the asset inventory, so devices outside it are not hidden	Enterprise asset inventory extract (Safeguard 1.1) and the date it was produced
Exception review	Whether each rule that departs from the allowlist has an owner, a reason and an end date	Exception register with approvals and periodic review records
Common finding: unlisted devices	Laptops or workstations that connect to the network but are absent from the inventory, so no firewall check applies	Reconciliation of network discovery results against the inventory (illustrative gap)
Common finding: disabled firewalls	Users or local administrators turning the firewall off, often to run a single application	Endpoint state reports showing devices that failed the enablement check and the remediation ticket
Common finding: allow-all rules	Broad rules such as any-to-any or permit-all added to fix connectivity, which defeat default deny	Policy export showing rule scope, plus change records for rules added after baseline

How to roll out default-deny firewalls across an endpoint fleet

This sequence moves end-user devices from allowing traffic by default to blocking everything except explicitly permitted services and ports. Each step produces a record that an assessor can check against the Safeguard 4.5 measures.

Confirm inventory and software prerequisites
The IT operations team checks that the enterprise asset inventory under Safeguard 1.1, the software inventory under Safeguard 2.1 and the secure configuration process under Safeguard 4.1 exist and cover the end-user devices in scope. Gaps are logged as blockers. The output is a reconciled device list with operating system versions and owners, plus a short statement that the prerequisite records are current enough to measure coverage against.
Document the permitted services baseline
The security engineering team, working with application owners, lists the inbound and outbound services and ports each device group needs, such as browsers, mail clients, collaboration tools and VPN clients. The baseline is written under the Safeguard 4.1 secure configuration process so it is reviewed with the rest of the configuration standard. The output is an approved baseline per device group that names each permitted service, its port and protocol, and its business reason.
Set default-deny in the OS or a port filter
Engineers configure the host firewall built into each operating system, or a managed port filter, to block all inbound and outbound traffic by default and to allow only the baseline rules. Configuration is written as code or policy so it can be reproduced and version controlled. The output is a tested policy package and a rollback procedure, confirmed on a lab image before any production device is touched.
Pilot on a controlled device group
A small group of representative devices, chosen across operating systems and user roles, receives the policy first. Helpdesk staff watch for broken applications, blocked updates and failed authentication flows. Each blocked flow found during the pilot is either added to the baseline with an owner or confirmed as unwanted. The output is a pilot report listing every change made to the baseline and the sign-off from the device group owner.
Handle exceptions with owners and expiry dates
Requests for traffic outside the baseline go through a written exception process. Each exception names a business owner, a technical justification, the specific service and port, and an expiry date after which it is removed unless renewed. The security team reviews the register at a set interval. The output is an exception register that shows who approved each opening and when it will close, which is the evidence an assessor will ask for first.
Enforce the policy across the fleet
Engineers apply the approved policy to the full device inventory through the endpoint management tool the organization already uses, in waves that match the pilot pattern. Devices that fail to receive or keep the policy are reported and investigated. The output is a fleet status report showing the share of in-scope devices running default-deny, with the remainder listed by reason and owner.
Monitor policy state and drift
The operations team checks on a recurring basis that each device still runs the approved policy, that no local user has disabled it and that new exceptions match the register. Compliance checks can be built with open-source tools such as Fleet policies or Wazuh configuration assessment, and the organization should confirm which checks each tool supports for its operating systems. The output is a recurring compliance report that feeds the coverage measure used in the Safeguard 4.5 assessment.

Evidence that shows end-user devices deny traffic by default

Safeguard 4.5 is proven by a chain of records, not a single screenshot: which devices exist, what each one allows, and whether the firewall on each device actually enforces that rule set. The cards below cover the artifacts that link those records together and how to keep them current between assessments.

Device inventory matched to firewall state

Start with an extract from the enterprise asset inventory (Safeguard 1.1) and match each end-user device to its firewall status. The CIS assessment specification treats the asset and software inventories as prerequisites for measuring Safeguard 4.5, so the extract must show every in-scope device, its owner and operating system, and whether a host firewall or port filter is enabled. Any device missing from the match is an unmeasured device. Check that the count of matched devices agrees with the inventory total.

Approved service and port baseline

The baseline is the written list of services and ports each device class may receive or send, approved by the owner of the device standard. It is the reference that makes default-deny testable, because an assessor can compare the rules on a device with the baseline and find anything that passes traffic without an entry. Confirm that the baseline names the device classes it covers, lists the protocol and port for each service, and carries a version date and approver.

Default-deny configuration exports

Keep exports or policy screenshots that show the default action is block for inbound and outbound traffic, with explicit allow rules above it. Store them from the management console or configuration management tool, not from a one-time demonstration. A rule set that ends in an allow-all entry fails the test even when most traffic is blocked, so the export should show the final default action clearly. Record the export date and the device group it came from.

Per-device compliance status samples

Samples of per-device status show that the policy is applied in practice. Fleet policies, written as yes or no osquery questions, can report which devices on each fleet pass or fail a firewall check, and the policies page lets you export those results. Wazuh Security Configuration Assessment can cover the same ground with policy checks against endpoints. Pull samples across operating systems and device groups, and explain every failing device in the record.

Exception register with approvals and expiry

Some users need a port that the baseline does not allow, such as a vendor application or a temporary test. Each exception should be a register entry naming the device, the service, the business reason, the approver, the risk owner's acceptance and an expiry date. An assessor will look for exceptions that never expire and for enabled rules with no register entry. Expired exceptions with live rules are the most common gap at review.

Change records and scheduled evidence pulls

Change tickets show how the baseline and firewall rules were modified, who approved each change and whether the change was tested before rollout. Keep these with the configuration history from version control or the management tool. Between audits, schedule pulls of inventory matches, exports and status reports, for example monthly, and store them with dates in a locked evidence location, so the record covers the whole period rather than the week of the audit.

Open-source tools for firewall rules, logging and compliance checks

OPNsense is a stateful packet filter, so its strongest contribution to Safeguard 4.5 is at the network edge, where rules pass, block or reject traffic by source, destination, port and protocol. It does not install or manage a firewall on end-user devices, so it cannot by itself prove that a laptop or workstation denies traffic by default. Its value to this Safeguard is the documented allow list it enforces for the segments those devices sit in, together with a log of rule matches that can be reviewed in the live log view.

Default deny rules: Build the rule set so that the final rule blocks everything not explicitly permitted, and keep that rule visible in the exported configuration.
Aliases for permitted services: Use aliases for address groups and port lists so each allowed service has one named, reviewable definition.
Rule-match logging: Enable logging on rules that matter for the assessment so that blocked and allowed attempts can be shown to an assessor.
Change history: Store exported configurations under version control so that every change to a permitted service has a date and an owner.

Confirm with your own network team which device segments, if any, are protected by the edge firewall, and confirm the endpoint firewall coverage for each operating system in your fleet separately.

What meeting Safeguard 4.5 costs in money and effort

The money spent on Safeguard 4.5 is mostly people's time: designing the deny-by-default baseline, handling exceptions and collecting evidence. Open-source firewall and policy tools remove license lines, but the work recurs as the device fleet and business needs change, so ask for a written scope that separates one-time build work from ongoing effort.

Open-source tooling licenses

Host-based firewall or port filter tooling on end-user devices is often built into the operating system, and the open-source options named for this Safeguard carry no license fee when self-hosted. Managed OS features, endpoint management suites or vendor agents may still carry their own cost, so confirm which components your devices already include. This is a one-time check at scoping and again at each renewal or platform change.

Baseline and rule design

Someone must define which services and ports each device class needs, then write the deny-by-default ruleset. This is the largest one-time effort and is usually engineering time, sometimes supported by an implementation partner under a fixed-scope agreement. Ask the quote to list the device classes covered, the number of rule sets and who signs off on the permitted services.

Pilot and exception handling

A pilot group shows which legitimate applications break under a default-deny posture before rollout. Every later request to open a port becomes an exception that needs an owner, a justification and an expiry date. Exception volume is the factor that most often drives recurring effort, so ask how the quote estimates requests per quarter and who approves them.

Ongoing evidence collection

Assessors look for proof that the firewall is enabled and the permitted list matches approved rules across the device inventory. Collecting that proof is recurring work: exports, policy results and change records for each review cycle. Ask whether the scope includes scheduled evidence pulls, who performs them and where the results are stored.

Assessor sampling and remediation

An independent assessor selects a sample of devices and tests them, and the organization pays for the time spent preparing for and responding to that testing. Failed samples lead to remediation work and retesting. Your own staff and any consultant time should be budgeted for this, because the assessor does not issue findings as part of readiness work.

Quote inputs that drive cost

The main cost drivers are device count, the number of distinct operating systems and device roles, how often business applications change and the exception volume. Before requesting a quote, gather an accurate asset inventory, a list of applications and their network needs, and the current firewall state of the fleet. A written scope tied to these inputs lets you compare proposals fairly.

Who owns the device firewall: your team, a partner and the auditor

Your organization owns Safeguard 4.5 and every decision that comes with it. The firewall policy that blocks all inbound and outbound traffic by default, the list of services and ports you explicitly permit, and the decision to accept any device that cannot run a host firewall all sit with your security leadership and the business owners of those systems. An implementation partner such as DeployOpen can design a baseline, write rule sets, roll them out to endpoints in your environment, configure monitoring and build the evidence pipeline that shows coverage over time. The partner works inside your cloud accounts, data centers or endpoint management tooling, but it does not approve exceptions, accept residual risk or declare the Safeguard met. Those outcomes belong to you, and you should be able to name the person who signs each one. In practice, the work that is usually outsourced is the parts that take specialist time up front: drafting the default-deny baseline per device class, testing rule sets against real application traffic, staging the rollout, and automating the reports that show which devices pass or fail. The work usually kept in-house includes exception approval for a business application that needs an unusual port, risk acceptance for devices that cannot be brought into scope, and the periodic review of the permitted services list against your asset and software inventories, which Safeguards 1.1 and 2.1 supply. Ask any partner to show in writing which of these items it performs, which it only supports, and which it will not touch.

Auditor independence draws the line. An independent auditor, assessor or certification body tests the control and issues any report or certificate. If the same firm designed the rules and then tests them, the independence of the assessment is weakened, so many organizations keep the implementation partner and the assessor separate. Confirm with your assessor, before work starts, which evidence they will accept, whether they will sample devices themselves, and whether the partner's configuration exports count as system-generated evidence or need corroboration. The CIS Controls Assessment Specification describes what is measured for Safeguard 4.5, but it does not decide what your assessor will accept, so that question should be settled with the assessor directly.

Safeguard 4.5 questions buyers ask before hiring help

How much effort does Safeguard 4.5 take to implement?

The effort depends mostly on how many device types you run, how many applications need network access, and whether a deny-by-default posture already exists on any of them. Safeguard 4.5 asks that end-user devices run a host firewall or port filter that blocks all traffic by default and allows only explicitly permitted services and ports. Most of the work is building and approving that allowlist, testing that business applications still function, and rolling out policy in stages. Costs have two parts: internal time from network, endpoint and application owners, and any external implementation work, which is quoted from a written scope. Ask any partner to break the quote into discovery, policy design, pilot, rollout and evidence collection so you can see where effort sits.

Can our team implement Safeguard 4.5 with open-source tools?

Yes, a capable team can, and several open-source components cover different parts of the job. OPNsense is a stateful packet filter with rules that pass, block or reject traffic by source, destination, port and protocol, which suits network-edge policy rather than endpoints. Fleet policies are yes or no osquery questions that show which devices pass or fail each check, which helps you confirm firewall state across the fleet. Wazuh Security Configuration Assessment scans endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom checks. Confirm with each vendor which endpoint firewall controls each tool can read or enforce on your operating systems before you commit to a design.

How long does a Safeguard 4.5 rollout take?

The duration depends on the drivers below, not on a fixed period, so ask for a timeline built from your own environment. The main factors are the number of device builds and operating systems, the completeness of your asset and software inventories (Safeguards 1.1 and 2.1), the maturity of your secure configuration process (Safeguard 4.1), how many business applications need an explicit port exception, and how quickly change approvers can review them. Rollouts that start in a pilot group and expand in waves usually take longer to plan but reduce the risk of blocking users. A written scope should state the milestones and what each one depends on.

Can a partner make our Safeguard 4.5 audit pass?

No. A partner can prepare your firewall configuration, policy documentation, testing records and evidence, but only the independent assessor or auditor decides whether your controls meet the requirement. The organization owns its controls and their results. A good partner will tell you what evidence an assessor is likely to request, such as policy exports, device coverage reports and exception approvals, and will be explicit about what it did and did not verify. Be cautious of any promise of a pass, because the outcome depends on the assessor's testing and your actual operation of the control.

What does the work need from our organization?

Expect to provide access and time from several groups. Typically this includes read access to asset and software inventories, endpoint management consoles and current firewall settings, named approvers for port exceptions and policy changes, application owners who can confirm required services, and change windows for staged rollouts. Someone must own the final allowlist and sign off on exceptions. Agree these responsibilities, the approval path and the change calendar in writing before work starts, so delays do not come from unclear ownership.

Is an endpoint firewall enough on its own?

No. Safeguard 4.5 covers end-user devices, and it sits alongside Safeguard 4.4 for servers, the network controls in Control 12 and the monitoring in Control 13. An endpoint firewall that is switched off, overridden locally or missing from some devices does not meet the requirement, so coverage and enforcement both need checking. Ask for the measurement approach from the CIS Controls Assessment Specification and confirm how your organization will demonstrate coverage across all in-scope devices.

What evidence should we expect to produce for Safeguard 4.5?

Assessors usually look for a documented policy that requires deny-by-default filtering, configuration exports or management console screenshots showing the setting applied, a coverage report across the device inventory, records of approved exceptions with business justification, and evidence that failing devices are identified and remediated. Ask your partner to map each artifact to the measures in the Assessment Specification so gaps are visible early. The exact evidence an assessor accepts is their decision, so confirm expectations with them before collecting it.

How DeployOpen scopes and prepares Safeguard 4.5 evidence

DeployOpen works as a fixed-scope implementation partner for Safeguard 4.5. The organization still owns its control and its risk decisions. DeployOpen's part starts with a written scope that names the device population in bounds, such as corporate laptops, desktops and any other end-user endpoints, and the baseline each device must meet: a default-deny host firewall or port filter, a permitted-services list per device group, and the exceptions that need an owner and an expiry date. Before any policy is written, the inventory work behind Safeguards 1.1 and 2.1 and the documented process from Safeguard 4.1 should be checked, because the assessment specification relies on them as inputs. Ask for the scope, the deliverables and the acceptance criteria in writing before work begins.

Implementation happens inside the client's own environment, using the management tools they already run or have agreed to adopt. Depending on the estate, that can mean configuring the built-in firewall profiles of managed endpoints, or deploying a firewall policy from a management plane. For reporting, open-source options such as Fleet can express a default-deny check as a yes or no policy and show which devices pass or fail it, and Wazuh's Security Configuration Assessment can run configuration checks against endpoints. Whether a given platform can enforce the policy on each operating system in scope is a question to confirm during scoping, not something to assume from its feature list. Testing on a pilot group before broad rollout reduces the chance that a blocked service disrupts users.

For evidence, DeployOpen prepares what the client and their assessor will need to see: the policy baseline, the permitted-services list with its approvals, the exception register, the pass or fail results per device over time, and records of how failing devices were remediated. The coverage metric in the assessment specification is only as credible as the device population behind it, so the client should confirm that the reporting covers every in-scope device, including devices that are off the corporate network for long periods. DeployOpen does not issue reports, attestations or certifications. Independent auditors and certification bodies do that work. Ongoing checks, policy changes as services are added, and periodic re-testing of the baseline can be set up as a retainer after the fixed-scope work is complete.

Safeguard 4.5 Implement and manage a firewall on end-user devices