Safeguard 13.9 Port-level access control: requirements and evidence

Port-level access control in CIS Safeguard 13.9: what an assessor will look for

Safeguard 13.9 asks for port-level network access control, using 802.1X or a similar protocol, which can rely on certificates and user or device authentication. If you are an IG3 enterprise preparing for a CIS Controls assessment, the question an assessor will ask is simple: when a device plugs into a switch port in your building or data center, does the network verify who or what it is before it gets access? The underlying risk is an unauthenticated device, such as a rogue laptop, a contractor's personal machine or an attacker's implant, gaining network reach simply because a wall jack is live. Safeguard 13.9 sits in the Network asset class, under the Protect security function, and it is placed in Implementation Group 3 only, one of the 23 Safeguards reserved for IG3.

This is hard for reasons that have little to do with the protocol itself. The first dependency is Safeguard 1.1, the detailed enterprise asset inventory, which the CIS Controls Assessment Specification lists as a prerequisite for measuring 13.9. You cannot decide which devices should authenticate if you do not know what exists. The second is readiness on both sides of the port: switches must support and be configured for the authentication protocol, and endpoints must supply credentials, including printers, cameras, building systems and other devices that cannot run a supplicant. The third is the certificate lifecycle. Certificate-based authentication depends on a certificate authority, enrollment, renewal and revocation, and an expired certificate can lock out a device as effectively as an attacker would be stopped.

The CIS Controls Assessment Specification does not prescribe a product or a design. It scores coverage through three metrics: Authenticator Coverage (the share of properly configured authenticators), Authentication Server Coverage (the share of properly configured authentication servers) and Client Authentication Certificate Coverage (the share of assets properly configured for authentication certificate coverage). Your task before an assessment is to define the population for each metric from your inventory, then measure how much of it is genuinely configured. Confirm with your assessor which asset populations they will sample, and confirm the exact measurement method in the specification at the Safeguard 13.9 section before you build your evidence set.

Which switch ports, devices, users and certificate authorities fall under 13.9

Safeguard 13.9 is only as large as the scope you draw around it. The cards below separate the network elements, endpoints and identity services that a 802.1X deployment touches, so the organization can decide what it controls, what it measures and what evidence an assessor will ask for. Start from the asset inventory, because the assessment specification treats Safeguard 1.1 as a prerequisite for measuring 13.9.

Asset inventory as the starting point

Safeguard 1.1 asks for a detailed enterprise asset inventory, and the CIS Controls Assessment Specification lists it as a prerequisite for measuring Safeguard 13.9. Without it, you cannot state how many endpoints should authenticate or prove that unknown devices are blocked. Confirm that the inventory records each switch, access point, endpoint and server with an owner and a network location before you define the 802.1X boundary.

Switch ports and access points

Decide which switch ports and wireless access points enforce port-level access control. Edge ports used by users, printers and phones usually sit inside scope, while uplinks and trunk ports between core switches are often managed through a different control. Record each port class in the inventory. For wireless, confirm whether the access points authenticate clients through the same RADIUS path as wired ports, because a split design creates a gap the assessor will test.

Managed and unmanaged endpoints

Managed laptops and servers can present certificates or supplicant credentials from a central tool. Unmanaged endpoints, such as contractor devices or personal phones, may only support user credentials or need a guest path. The scoping decision is which device classes must authenticate with a certificate, which may use user credentials, and which are denied. Document that split, because the Client Authentication Certificate Coverage metric depends on it.

Guest and IoT segments

Guest networks and IoT segments are where unauthenticated or hard-to-patch devices usually connect. Decide whether these ports fall under 13.9 or under segmentation controls in 13.4. A common approach is to place them in a separate VLAN with a guest or quarantine policy assigned after failed authentication. Confirm with the network team that failed 802.1X clients land in the intended segment and that the decision is written into the scope statement.

User identities and directory sources

Port-level access control is only as strong as the identity source behind it. Identify which directory or identity provider authenticates users, which groups map to VLAN or policy assignments, and who approves changes to those mappings. Users, their groups and their authentication methods all become part of the evidence set. Confirm that leavers are removed from the directory so their credentials stop working at the port.

Certificate authority and RADIUS servers

The RADIUS servers and the certificate authority that issues client certificates are part of the control, not merely supporting tools. If a compromised CA can issue client certificates, the port control fails. Decide whether the CA and RADIUS servers are in scope for 13.9 or for other controls, and record their hosting, administrator access and patching. FreeIPA includes an integrated certificate authority based on Dogtag, and OpenBao's PKI secrets engine can issue dynamic X.509 certificates, so the choice of issuer should appear in the scope document.

How the CIS Assessment Specification measures 13.9 and what an assessor requests

The table sets out the three metrics the CIS Controls Assessment Specification uses for Safeguard 13.9, how each one is tested, and the evidence an assessor usually asks for. Read each row as a question the assessor will put to your environment, and use the common findings column to check your own port-level access control before fieldwork begins. The specification defines what to measure, not how, so the test approach shown is a typical method and the conclusion always comes from an independent assessor.

Metric	Test approach	Evidence an assessor typically requests	Common findings
Authenticator Coverage (share of properly configured authenticators)	Count the switch ports, wireless controllers and other access points that enforce authentication, then compare that count with the port inventory from Safeguard 1.1 to find the share that is properly configured.	Switch and controller configuration exports showing 802.1X enablement per port, port-to-asset mapping, and the authenticator inventory.	Ports left in open or MAC-bypass mode, unmatched ports that exist in the switch config but not in the asset inventory, and guest or voice VLAN settings that bypass authentication.
Authentication Server Coverage (share of properly configured authentication servers)	Confirm that every authenticator points to an authentication server that is correctly configured, reachable and covering the intended user and device directories.	RADIUS or authentication server configuration, server list referenced by each authenticator, directory binding settings and server redundancy records.	A single server without fallback, stale server addresses left on older switches, and servers that accept requests from unapproved clients.
Client Authentication Certificate Coverage (share of assets properly configured for authentication certificates)	Sample assets that authenticate with certificates, check that each holds a valid certificate issued by the approved authority and that the certificate is enrolled and renewed as configured.	Certificate issuance records, enrollment logs, asset-to-certificate reconciliation against the asset inventory, and certificate expiry and renewal reports.	Devices without a certificate that still authenticate by password, expired or unrenewed certificates, and device classes such as printers, IoT sensors or legacy systems that the supplicant cannot support.
Scope and prerequisite dependency	Confirm that the enterprise asset inventory from Safeguard 1.1 is complete before any coverage percentage is calculated, because an unknown device cannot be measured.	Current asset inventory export, the date it was last reconciled against network discovery, and the rules used to decide which assets are in scope.	Coverage figures calculated on an incomplete inventory, and wireless or remote assets that were left out of the denominator without a documented reason.
Who issues the conclusion	The organization runs its own measurements and prepares evidence. An independent assessor tests the evidence, decides whether each metric is met and issues the conclusion.	Written measurement method, measurement results with dates, and a record of the exceptions and their approvals.	Self-assessed results presented without reproducible method or without the raw exports that support them.

How to roll out 802.1X port authentication without locking out the business

A staged rollout confirms what is on the network, builds the identity and certificate foundation, and moves ports to enforcement in controlled groups so every step leaves evidence an assessor can test against Safeguard 13.9.

Confirm the enterprise asset inventory
Start by checking the detailed asset inventory required by Safeguard 1.1, because the assessment specification treats it as a prerequisite for measuring 13.9. The network team and asset owners reconcile switch ports, wired devices, printers, IoT equipment and unmanaged endpoints against the inventory, and flag devices that cannot run a supplicant. The step closes when every switch port is mapped to a location, an owner and an expected device type, and the list of non-supplicant devices has a documented handling decision such as MAC Authentication Bypass or a segregated port group.
Define the authentication policy and certificate model
Decide which identities authenticate at the port, whether users, devices or both, and which EAP method each population uses. Security architecture and the identity team document the certificate model: which certificate authority issues client and server certificates, how certificates are enrolled and renewed, and how revoked devices are handled. The output is a signed authentication policy and certificate standard that names the owners of each identity source, so the three assessment metrics (authenticator coverage, authentication server coverage and client certificate coverage) have a defined target.
Stand up authentication servers and a certificate authority
Deploy the RADIUS authentication servers and the certificate authority in a redundant configuration inside your own infrastructure. An open-source option is FreeIPA, which includes an integrated certificate authority based on Dogtag, while OpenBao's PKI secrets engine can issue short-lived X.509 certificates to services without manual key and CSR handling. Your team confirms that each tool supports the EAP methods and certificate lifecycle you chose in the previous step, because capability varies by version. The step closes with test authentications from a lab switch and a documented server build, including certificate chain and revocation checks.
Pilot in monitor or fallback mode
Enable port authentication on a small set of non-critical ports in a mode that logs failures without cutting access, or that falls back to a guest or quarantine VLAN. Operations staff review authentication logs daily, correlate failures with the inventory from step one, and fix supplicant configuration, certificate enrollment and switch settings as they appear. Ask your switch vendor to confirm which monitor and fallback modes the hardware supports. The pilot is complete when failure causes are classified and recorded, and the team has tested recovery for a failed authentication server.
Enforce authentication by port group
Move from monitor to enforcement one port group at a time, starting with groups that carry the lowest operational risk and ending with critical areas such as data center, clinical or production floors. Before each change, the team confirms that every device in the group is in the inventory and has a valid certificate or an approved exception. The change record for each group lists the switch configuration, the rollback step and the sign-off from the business owner. Each completed group produces a dated configuration snapshot and authentication logs that show the coverage measures for that group.
Document exceptions and sustain coverage
Record every device that cannot authenticate with 802.1X, including the compensating control, the business owner, the risk acceptance and the review date. Set up recurring reports on authenticator and certificate coverage so unauthenticated ports and expiring certificates surface before they cause outages. An independent assessor will test whether the exception register is current and whether the coverage figures match the switch configuration, so ask your team to confirm the report source and retention before the assessment begins. The step closes when the exception register, coverage reports and change records form one evidence set mapped to Safeguard 13.9.

Choosing certificates, user or device authentication for port access

The core decision for Safeguard 13.9 is which identity the port admits: a user, a device, or both together. User-based authentication ties access to a person's directory account, which suits shared or mobile laptops but says nothing about whether the machine is managed. Device-based authentication proves the hardware is known, which covers printers, cameras and other non-interactive assets that have no user. Combined authentication requires both, and is the stronger posture for corporate endpoints because a stolen password alone or an unmanaged device alone is not enough to reach the network. The Safeguard names certificates as the mechanism, and certificates are the strongest option it describes because the credential is a cryptographic key that is hard to phish or copy, unlike a password. Confirm with your identity team which combination your directory and endpoint estate can support before writing the policy.

Certificates shift the work into lifecycle management: issuing a certificate to each user or device, renewing it before expiry, and revoking it when someone leaves or a device is lost. Each step can fail silently, and an expired certificate locks a port-connected asset out of the network. An internal certificate authority reduces this burden. FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag for issuing and managing certificates, which suits organizations already running FreeIPA for identity. OpenBao (MPL-2.0) offers a PKI secrets engine that issues dynamic X.509 certificates, so a service obtains a certificate without manually generating a key and certificate signing request and waiting for signature. Short-lived certificates issued this way lower revocation risk, because a compromised credential expires quickly, but they require that your authenticator can renew automatically. Confirm that your RADIUS server and switches accept the certificate chain and renewal method you choose, since 802.1X support differs by vendor and firmware.

Plan the decision as an inventory question first. Safeguard 1.1, the detailed asset inventory, is a prerequisite for measuring 13.9, and the assessment specification scores Client Authentication Certificate Coverage, the share of assets properly configured for authentication certificates. An asset without a recorded owner, type and expected port behavior cannot be counted, so unknown devices become exceptions at audit time. Before enabling enforcement, list which assets will use user authentication, which will use device certificates and which need a documented exception such as a printer with no supplicant. Then test one authentication path end to end, including certificate expiry and revocation, in a pilot VLAN. The organization owns this decision and its evidence; a DeployOpen engagement would prepare the systems, configurations and records, while only an independent assessor can judge whether the control is effective.

Evidence that passes 13.9 and how to keep it current between audits

An assessor testing Safeguard 13.9 will want proof that 802.1X enforcement exists on the switches, that authenticators and authentication servers are configured correctly, and that every enterprise asset is accounted for. The artifacts below connect to one another, so each one should be refreshed on its own schedule rather than rebuilt in the weeks before an audit.

Authenticator and authentication server exports

Export the configuration of every authenticator (switches, wireless controllers, VPN concentrators) and every authentication server (RADIUS or equivalent) on a fixed schedule and store the exports under version control. The CIS Controls Assessment Specification scores Safeguard 13.9 partly on the share of properly configured authenticators and authentication servers, so an assessor will compare these exports against the device list. Check for drift, such as an authenticator that falls back to open access on a failed server response.

Switch port 802.1X enforcement records

Keep a current record of which switch ports enforce 802.1X authentication, which are in monitor or fallback mode, and which are exempt. Generate this from the switch configuration rather than from a spreadsheet, and compare it with the port map each quarter. An assessor will ask why a port is not enforcing, so every non-enforcing port should trace to a documented reason in the exception register.

Client certificate inventory and coverage reconciliation

Maintain an inventory of issued client authentication certificates, including subject, issuing authority, expiry and the asset each certificate belongs to. Reconcile that list against the enterprise asset inventory from Safeguard 1.1, which the assessment specification names as a prerequisite. Assets without a certificate, and certificates tied to assets that no longer exist, are the two gaps that depress the Client Authentication Certificate Coverage metric.

Authentication logs and failure review

Retain authentication logs from the RADIUS or equivalent server and the switches, and forward them to the central log platform used for Control 13.1 alerting. Review repeated failures, rejected certificates and authentications from unknown devices on a set cadence. These logs show an assessor that enforcement is operating in practice, not only configured on paper.

Exception register with approvals

Record every port, device or user group that is excluded from 802.1X enforcement, with the business reason, compensating control, named owner, approver and an expiry or review date. Each entry should be re-approved at its review date. An assessor testing 13.9 is likely to sample exceptions first, so an undated or unapproved exemption is a common finding.

Periodic coverage reports

Produce a coverage report on a fixed schedule that calculates the three CAS metrics: authenticator coverage, authentication server coverage and client authentication certificate coverage. Keep each report with its inputs and the date it was generated, so a reader can recreate the figure. Trend lines matter more than a single snapshot, because they show whether coverage is holding between audits.

What meeting Safeguard 13.9 costs in licenses, engineering and upkeep

This table lists the cost components of deploying port-level access control under Safeguard 13.9, who is typically paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since no price or duration for this work is published in the supplied material and every figure depends on the written scope of your environment.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
NAC or RADIUS software	Vendor license, or no license fee for self-hosted open-source options such as FreeRADIUS or OpenBao-issued certificates	Commercial: recurring subscription. Open source: one-time build, then recurring maintenance	Endpoint count, number of sites, high availability design, and whether the platform needs vendor support
Certificate authority setup	Internal staff or implementation partner; FreeIPA includes an integrated CA based on Dogtag, and OpenBao offers a PKI secrets engine	One-time design and build, then recurring operation	Whether a root CA already exists, hierarchy depth, HSM use, and how many certificate profiles you need
Switch and wireless reconfiguration	Network team or partner engineers, plus any hardware replacement for switches that cannot run 802.1X	One-time per port or access point, plus recurring change work for new devices	Port count, mix of switch vendors, legacy equipment without supplicant support, and wireless controller model
Endpoint supplicant deployment	Internal endpoint or desktop team, or the endpoint management vendor	One-time rollout, then recurring for new builds and unmanaged devices	Device diversity (managed laptops, printers, IoT, medical or industrial devices) and whether devices can be enrolled by MDM
Asset inventory prerequisite (Safeguard 1.1)	Internal asset owners; the CIS assessment specification names Safeguard 1.1 as a prerequisite for measuring 13.9	One-time baseline, then recurring reconciliation	Quality of the existing inventory and how many unknown devices are discovered during the baseline
Certificate renewal and upkeep	Internal operations, or the implementation partner under a retainer	Recurring	Certificate lifetime, automation level (for example, dynamic issuance versus manual CSR handling), and revocation process
External testing or review	Independent security testing firm or assessor, paid per engagement	Recurring per test cycle	Scope of the test, whether bypass of port authentication is included, and number of network segments
Auditor sampling	External auditor or assessor during the assessment period	Recurring per assessment cycle	Number of sites and assets sampled, and quality of the evidence kept for authenticator and server coverage

Who owns 13.9 in-house, who a partner helps with, and what the auditor tests

Your organization owns Safeguard 13.9. That means deciding whether port-level access control applies to each part of the network, setting the authentication policy, approving exceptions for devices that cannot authenticate, and accepting the residual risk when a port stays open. These are management decisions, and no partner or auditor can make them for you. Your team also keeps the asset inventory that the assessment specification treats as a prerequisite, because you cannot measure authenticator coverage for devices you have not identified.

Policy and scope: Define which ports, switches, wireless controllers and VPN concentrators must enforce 802.1X or an equivalent, and which exceptions you accept.
Authentication choices: Decide whether access uses user credentials, device certificates or both, and who approves that design.
Exception handling: Record each unmanaged or legacy device, its owner, compensating controls and review date.
Inventory ownership: Maintain the enterprise asset inventory (Safeguard 1.1) that feeds the coverage metrics.
Operations: Run the access control service day to day, respond to failed authentications and keep certificate lifecycles current.

Before engaging anyone, confirm that you have named owners for each of these items and a written exception process.

Which self-hosted open-source tools support 13.9 evidence

Does FreeIPA handle 802.1X port authentication for switches and Wi-Fi?

FreeIPA does not perform port-level network access control by itself, but it is a common identity source behind it. FreeIPA is licensed under GPL-3.0-or-later and includes an integrated certificate authority based on Dogtag for issuing and managing certificates. In a 13.9 design, that CA can issue the client authentication certificates that devices and users present during 802.1X, and the directory can hold the identities a RADIUS server checks against. Whether your switches and wireless controllers can use FreeIPA-backed certificates through a RADIUS server is a vendor question. Confirm 802.1X and RADIUS support for each switch and wireless vendor in your estate before you rely on this design.

How does OpenBao issue certificates for device authentication?

OpenBao issues certificates through its PKI secrets engine, which is licensed under MPL-2.0. The engine issues dynamic X.509 certificates, so a service or device can obtain a certificate without someone manually generating a key and certificate signing request and waiting for a CA to sign it. That shortens the path to a current client authentication certificate and makes renewal routine, which supports the Client Authentication Certificate Coverage metric. OpenBao does not authenticate ports itself. Your team still needs a RADIUS or equivalent authentication server that trusts the issuing CA, and you should confirm that your switch and wireless platforms accept the certificate formats and renewal behavior you choose.

Can OPNsense replace 802.1X for port-level access control?

No. OPNsense is a stateful packet filter, licensed under BSD-2-Clause, and it does not authenticate devices or users at the switch port, so it is not a substitute for 802.1X. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases let you group addresses and ports into named policy objects. You can enable logging on each rule match and review the events in the live log view. That helps you show how segment and port policy is enforced and reviewed, which is useful evidence alongside 13.4 and 13.9 records. Authentication still has to happen at the access layer through 802.1X or a similar protocol on your switches and wireless controllers.

What evidence should I collect to show 13.9 is working?

Assessors look for records that tie each in-scope port and wireless access point to an authentication policy, plus proof the authenticators and servers are configured correctly. Useful artifacts include an asset inventory that matches the switch and access point configurations, RADIUS server configuration exports, certificate issuance and renewal logs from your CA, and switch port configuration snapshots showing 802.1X enabled. The CIS Controls Assessment Specification scores this safeguard with Authenticator Coverage, Authentication Server Coverage and Client Authentication Certificate Coverage, so keep counts and dates for each. Your organization owns these records. An independent assessor decides whether they are sufficient.

Why does 13.9 depend on an accurate asset inventory?

The CIS Controls Assessment Specification lists Safeguard 1.1, the detailed enterprise asset inventory, as a prerequisite for measuring 13.9. Port-level access control can only be verified for ports and devices you know about. If an unmanaged switch, printer or access point sits on a port without an authentication policy, your coverage figures will be wrong or incomplete. Before you deploy, reconcile switch port maps, DHCP and discovery data, and your asset register. Ask any implementation partner to show how the inventory feeds the authenticator and server coverage counts.

What should I ask a partner about open-source tooling for 13.9?

Ask which components they will deploy, which parts are open source and under what license, and which parts depend on your existing network vendors. A clear written scope should name the CA, the RADIUS or authentication server, the certificate issuance workflow, the switch and wireless configuration work, and the evidence exports. Ask how they will confirm 802.1X and RADIUS capability on your specific hardware before any change is made, and who owns each record after handover. Engagements are fixed-scope and agreed in writing, so the scope should answer these questions before work starts. DeployOpen prepares systems and evidence, and an independent auditor issues any report.

Which parts of 13.9 can my own team run without outside help?

Teams with network engineering and identity skills often handle the core work themselves, provided they can test before they change production switches. The main tasks are building a certificate authority or issuance path, configuring a RADIUS server, enabling 802.1X on a pilot set of ports, and documenting exceptions for devices that cannot authenticate. The hardest part is usually phased rollout without locking out legitimate users, which needs a rollback plan and a test lab. Outside help is most useful for scoping the rollout, validating vendor behavior and preparing the evidence that an assessor will test. Costs depend on the number of switches, access points, identity sources and sites, and on how much testing is needed.

Where 13.9 programs fall short and how to close each gap

Safeguard 13.9 programs usually fail in the places where the network, the asset list and the assessment metrics meet. The gaps below cluster around inventory accuracy, silent exclusions, certificate lifecycle, enforcement mode and exception governance, and each has a concrete fix an assessor can verify.

Incomplete asset inventory skews coverage

The assessment specification measures 13.9 with coverage metrics, and each metric is only as good as the denominator. Safeguard 1.1, the detailed enterprise asset inventory, is a prerequisite, so an inventory that omits switches, access points or laptops inflates the apparent share of properly configured assets. Reconcile the 802.1X authenticator list against the inventory from discovery tooling each quarter, and record every mismatch as a finding with an owner. Ask your assessor which inventory source they will accept as the population for testing.

Printers and IoT excluded silently

Printers, cameras, badge readers and building controllers often cannot run a supplicant, so teams leave them off the 802.1X policy and never record why. The gap is not the exclusion itself but the absence of a documented decision. Create a separate MAC authentication bypass or device-profile group for these assets, tag each one in the inventory with its authentication method, and report the group as its own metric. An assessor will look for these devices in the population, not for their absence from it.

Certificate expiry causing outages

Client authentication certificates underpin the Client Authentication Certificate Coverage metric, and an expired certificate can lock users or devices off the network at once. Automate issuance and renewal through an internal certificate authority such as the one in FreeIPA, which uses Dogtag, or a PKI secrets engine that issues short-lived X.509 certificates. Set alerts well ahead of expiry and test a renewal on a pilot group before the production rollout. Confirm with your identity team who owns the CA key and how revocation is handled.

Monitor mode left on indefinitely

Many teams deploy 802.1X in a monitor or low-impact mode to avoid breaking users, then never move to enforcement. Safeguard 13.9 calls for port-level access control, so a port that logs failures but admits every device does not meet the intent of the safeguard. Set a dated cutover plan per site, track the count of unauthenticated sessions that would have been blocked, and require sign-off before the mode change. Ask your assessor how they will distinguish a staged rollout from a permanent exception.

No reconciliation between port configs and the asset list

Switch port configurations, the authentication server database and the asset inventory often drift apart after moves, adds and changes. A port may be configured for 802.1X while the device on it is no longer in the inventory, or an inventory entry may point to a port that no longer exists. Export port configuration from each switch on a schedule, compare it with the inventory and the authentication server records, and resolve each difference through the change process. Store the comparison output as evidence of the authenticator and server coverage metrics.

Exceptions without owners or review dates

Every port that runs without authentication, and every device that uses a fallback method, is an exception to 13.9. Exceptions tend to accumulate when no one owns them and no one sets an expiry. Maintain an exception register with a named business owner, a technical justification, a compensating control such as segmentation or port security limits, and a review date that the owner must renew. Confirm with your governance team which forum approves new exceptions and how the register links to your risk assessment.

Common questions about meeting CIS Safeguard 13.9

How much effort does meeting Safeguard 13.9 take?

The effort depends on how many switch ports, wireless access points, and endpoints must be brought under authentication, and on how much of the asset inventory already exists. Safeguard 13.9 is an IG3 safeguard, so it sits in the most demanding tier of the CIS Controls. The assessment specification measures three things: authenticator coverage, authentication server coverage, and client authentication certificate coverage. Each one is a share of properly configured components, so the work is largely about reaching full, verifiable coverage across the estate. Effort rises with the number of heterogeneous switches, legacy devices that cannot do 802.1X, and the amount of certificate lifecycle work. Ask any provider for a written breakdown by device class and by site.

Can our in-house team implement 13.9 without outside help?

Yes, many organizations do this internally, provided they have people who understand RADIUS, certificate authorities, switch configuration and endpoint supplicants. The skills gap is usually in certificate issuance and renewal, not in the switch configuration itself. Safeguard 13.9 also depends on Safeguard 1.1, the detailed enterprise asset inventory, so the team needs an accurate device list before enforcement can start. An outside partner can prepare the directory, certificate authority and policy components, and document the evidence, but the organization keeps ownership of its controls. Decide early which parts your staff will run after handover, because an authentication outage can block users across a site.

What does the network and endpoint work need from each team?

Network engineers must configure port authentication on switches and wireless controllers, define fallback behavior for devices that cannot authenticate, and test VLAN assignment for each outcome. Endpoint teams must deploy and manage supplicant settings and client certificates, and confirm that managed devices present them correctly. Identity or directory administrators own the authentication server and the user or device accounts it validates. Security and compliance staff define the policy, approve exceptions, and collect the metrics that the assessment specification uses. Agree on one owner for each function in writing before the first pilot, since gaps between these teams are the most common reason rollouts stall.

How long does a 13.9 rollout take?

The duration depends on scope, including the number of sites, switch models, endpoint types and the state of the certificate infrastructure. No fixed timeline applies across organizations, so treat any single number with caution. Ask for a written timeline that splits the work into inventory validation, pilot in monitor mode, phased enforcement by site, and evidence collection. A credible plan will also name the decision points where the organization can pause if a device class fails. Most fixed-scope engagements begin with an agreed statement of work, so the timeline should appear there before work starts.

Does Safeguard 13.9 require buying a specific product?

No. Safeguard 13.9 asks for port-level access control using 802.1X or a similar network access control protocol, which may use certificates and user or device authentication. It does not name a vendor or product. Organizations often rely on capabilities already in their switches, wireless infrastructure and directory services. Open-source components can fill gaps. For example, FreeIPA includes an integrated certificate authority based on Dogtag, and OpenBao's PKI secrets engine issues dynamic X.509 certificates. Confirm with each vendor whether their hardware and software support the required protocol and certificate workflow in your environment before you commit to a design.

How does 13.9 relate to Safeguards 13.5 and 12.7?

Safeguard 13.9 controls who and what can connect to a physical or wireless port on the internal network. Safeguard 13.5 controls access for remotely connecting assets based on their anti-malware status, configuration compliance and patch level. Safeguard 12.7 covers secure remote access through VPN. In practice, the three share identity sources and certificates, so one design decision affects all of them. An asset that authenticates at the port should still face posture checks when it connects remotely. Map the three safeguards together during design so that a single device record, certificate and policy serve each path, and keep the evidence for each safeguard separate.

Can a partner help the auditor without becoming the assessor?

Yes. A partner can prepare the configuration, document the design, collect metrics for the three assessment measures, and organize evidence so the auditor can test it efficiently. The partner cannot issue the assessment result or certify that the organization meets the safeguard. That judgment belongs to the independent assessor or auditor the organization engages. Keep the roles explicit in the engagement letter: the organization owns the controls, the partner prepares systems and evidence, and the assessor tests and reports. Ask the assessor early which evidence formats they accept, so the preparation work matches what they will examine.

How DeployOpen scopes and prepares 13.9 evidence

DeployOpen plans, implements, hardens and documents self-hosted platforms inside your own network, including the authentication path that 802.1X or a similar port access control design depends on. The work runs in your cloud accounts, data centers or air-gapped networks, under a fixed-scope written agreement that sets the switches, access points, authentication servers, certificate authority and client population in scope, the deliverables and the timeline before work starts. Scoping usually begins with the asset inventory, because the CIS Controls Assessment Specification expects Safeguard 1.1 to be in place before 13.9 can be measured. DeployOpen can help reconcile that inventory against the network devices and endpoints that will be asked to authenticate.

For 13.9, the scoping decisions that drive cost and evidence are the authenticator type (user credentials, device certificates or both), the authentication servers and their redundancy, the certificate issuance model, and the set of assets that must be configured for authentication certificate coverage. Self-hosted options such as FreeIPA, which includes a Dogtag-based certificate authority, or OpenBao's PKI secrets engine, which issues dynamic X.509 certificates, can be scoped as components of that design. DeployOpen configures them, documents the configuration and produces the records an assessor will ask to see, such as coverage reports for the three CAS metrics. Confirm with your own environment which of your switches and wireless controllers support the 802.1X features in scope before committing to a design.

DeployOpen does not issue audit reports, attestations or certifications. Your organization owns its controls and decides whether 13.9 is in scope for an external assessment. An independent auditor, assessor or certification body tests the controls and issues any report or certificate. DeployOpen prepares the systems, configuration baselines and evidence that the assessor reviews. Ask any implementation partner to state this boundary in the statement of work. To scope the work, request a quote based on your written requirements, including the number and type of network devices, the directory and certificate infrastructure you already run, and the assessment framework your auditor will use.

Safeguard 13.9 Port-level access control