Safeguard 12.7 VPN and AAA for remote devices

What Safeguard 12.7 VPN and AAA for remote devices asks for

Safeguard 12.7 requires that end-user devices authenticate to enterprise-managed VPN and authentication services before they reach enterprise resources. It sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. CIS places it in the Devices asset class and the Protect security function, which means the requirement concerns the laptops and phones people use off-network and the controls that stop them from reaching internal systems on trust alone. If your organization is answering a customer questionnaire about how off-network devices get in, this is the safeguard that question maps to. The risk is straightforward. A device that is not managed by the enterprise, or that connects with a weak password or no check at all, can reach internal applications, file shares and administrative interfaces as if it sat in the office. The safeguard is hard to meet because it depends on three other safeguards. You cannot confirm that a device is authorized without the detailed asset inventory in 1.1, and you cannot judge whether its VPN client is current without the software inventory in 2.1. The centralized AAA service in 12.5 is the place where the authentication decision is made and logged. Organizations that skip those prerequisites usually find that their VPN works but cannot show which devices use it. Before engaging anyone, confirm three things in your own environment: which devices are enterprise-managed and which are not, whether every remote session passes through the VPN and the central identity service, and whether the VPN and identity logs can be retrieved for a given date range. The CIS Controls Assessment Specification scores this safeguard on VPN compliance, AAA compliance and coverage, so you will need to show the share of remote assets that use the controlled path, not just that the path exists. Check the current specification entry for the exact measures before you scope the work.

Which devices, services and teams fall under Safeguard 12.7

Safeguard 12.7 applies to IG2 and IG3 enterprises and reaches every end-user device that connects to enterprise resources from outside the office network. The scope work comes down to deciding which devices, gateways, authentication services, applications and third parties sit inside the requirement, and documenting each decision so an assessor can trace it.

End-user remote device types

Start with the devices that actually reach enterprise resources from outside the office network: company laptops, company phones and tablets, and personal devices enrolled for work access. Each device class needs an answer on whether it can authenticate to the VPN and authentication services before it reaches anything internal. Confirm that the asset inventory from Safeguard 1.1 covers these devices, because 12.7 cannot be measured without it. Devices that only use cloud applications through a browser still need a documented decision on whether they are in scope.

Enterprise-managed VPN gateways

List every VPN concentrator, firewall-based VPN and VPN client application that the enterprise operates or controls. The VPN Compliance metric counts only properly configured VPN devices and software, so a gateway missing from the list is also missing from the score. Record the owner, configuration baseline and version for each gateway. Ask whether any remote access path bypasses the managed gateway, such as a direct port forward or a vendor-run tunnel, because that path would undermine the requirement.

Authentication services in the AAA path

Identify the directory, identity provider and multi-factor services that remote users authenticate against. The AAA Compliance metric measures the share of properly configured AAA services, and Safeguard 12.5 on centralized AAA is a prerequisite. Identity platforms such as authentik or FreeIPA can serve this role, but the organization must confirm which systems are authoritative for remote sign-in and that each one is documented and configured to the same standard.

Applications behind the gateway

Map which internal applications, file shares, administrative consoles and development environments are reachable only after VPN and AAA succeed. This list defines the resources that the Coverage metric protects. Applications that are published directly to the internet, or that accept logins without the gateway, need either an explicit exception with a documented owner or a change in routing. Web applications exposed through a reverse proxy should also be reviewed for the protections placed in front of them.

Contractor and third-party devices

Decide whether contractor laptops, vendor support sessions and managed service provider endpoints count as end-user devices. If they connect to enterprise resources, the usual answer is yes, and they need the same VPN and AAA path or a documented equivalent. Confirm how contractor accounts are created, how they are removed, and whether the provider's own tools are enrolled in the enterprise inventory. Contract terms should state these obligations so the provider can be assessed against them.

Teams that own each decision

Assign named owners for remote access policy, gateway operation, identity services, device inventory and application owner sign-off. Network, identity and endpoint teams usually hold different parts of the evidence, so a single owner should maintain the scope register. Confirm the scope with the Navigator mapping to NIST SP 800-53 Rev. 5 AC-17 and ISO/IEC 27001:2022 Annex A 6.7, 8.1 and 8.21 as a pointer for your own verification, not as a claim of equivalence. Ask your assessor which of these controls they will test alongside 12.7.

How an assessor tests Safeguard 12.7 against the assessment specification

This table sets out the three metrics the CIS Controls Assessment Specification uses to score Safeguard 12.7, with the test approach, evidence an assessor expects and findings that commonly appear for each. Read it as a starting point for agreeing method with your assessor before testing begins, since the specification defines what to measure and not how to measure it.

Metric or prerequisite	Test approach	Evidence requested	Common findings
VPN Compliance (share of properly configured VPN devices and software)	Assessor takes the VPN population from the agreed inventory, then checks each device or client configuration against the enterprise standard for encryption, authentication and access scope.	Configuration exports, a documented VPN baseline, change records and a sample of configuration screenshots or scripted output.	Unmanaged VPN clients, legacy protocols still enabled, or configurations that differ from the documented baseline.
AAA Compliance (share of properly configured AAA services)	Assessor confirms that VPN authentication is delegated to the centralized AAA service, then reviews identity provider settings for MFA, password or token policy and authorization rules.	Identity provider configuration, authentication policy exports, group or role mappings and logs showing authentication events.	Local accounts used for VPN sign-in, MFA not enforced for every group, or authorization granted to broad groups.
Coverage (share of remote assets using VPN and AAA)	Assessor compares the remote asset population against VPN and AAA logs, then samples assets that appear in neither list to confirm whether they are excluded or missed.	Reconciled asset list, VPN session logs, AAA logs and a documented rule for which assets count as remote.	Remote laptops or phones missing from the asset inventory, or assets that reach resources without any VPN session record.
Prerequisite: Safeguards 1.1 and 2.1 (asset and software inventories)	Assessor confirms that the device population used for Coverage and VPN Compliance comes from the detailed asset inventory and software inventory, and checks their last update.	Enterprise asset inventory, software inventory and a record of how each list is maintained.	Inventory omits remote or personally owned devices, so the Coverage denominator is understated.
Prerequisite: Safeguard 12.5 (centralized network AAA)	Assessor confirms that the AAA service used for VPN is the same centralized service described in 12.5, and checks that authorization and audit logging are enabled.	Architecture description of the AAA service, its integration with VPN and sample audit records.	VPN uses a separate directory from the one governing network AAA, so access decisions are inconsistent.
Completeness of the Coverage population	Assessor asks how remote devices are identified, then tests the list against network and identity records, including devices that authenticate without a VPN session.	Documented method for identifying remote devices, reconciliation output and exceptions with approval.	Exceptions granted without an owner or expiry date, or no method to detect remote devices outside the inventory.

How to implement Safeguard 12.7 in sequence

The sequence moves from confirming the inventories and central AAA that 12.7 depends on, through VPN and authentication configuration for each remote device class, to a recurring check that keeps the Coverage list current. Each step closes with a record an assessor can read.

Confirm the prerequisite inventories and central AAA
Before configuring anything for remote access, confirm that the detailed enterprise asset inventory (Safeguard 1.1), the software inventory (Safeguard 2.1) and centralized network AAA (Safeguard 12.5) exist and are current. The CIS Controls Assessment Specification lists these as prerequisites for measuring 12.7, so a gap here will surface in every later metric. The owner of the inventories and the AAA service signs off on the check. The output is a short prerequisite record naming each system, its owner and the date it was last reviewed.
Define the enterprise-managed VPN and authentication services
Write down which VPN gateways, client software and authentication services count as enterprise-managed for remote access, and which identity source they authenticate against. Name the directory or identity provider that holds the accounts, and state whether it is the same service that backs central AAA from 12.5. The security or IT architecture owner approves the list. The output is a service register that defines the scope of the VPN Compliance and AAA Compliance metrics, so the team and the assessor count the same systems.
Build a configuration baseline for each remote device class
Group remote devices into classes such as managed corporate laptops, managed mobile devices and any other approved end-user device, then write a VPN and AAA configuration baseline for each class. The baseline records the required VPN client settings, the authentication method, the AAA destination and the logging expected. Engineers apply it through the platform's configuration tooling, and the owner approves it. The output is a versioned baseline per device class that the VPN Compliance and AAA Compliance metrics can be checked against.
Enforce authentication before enterprise resource access
Configure the VPN and the applications behind it so that no enterprise resource is reachable until the user has authenticated to the central authentication service. Open-source options such as OPNsense for stateful rules, authentik for OIDC, SAML, LDAP and RADIUS delegation, and FreeIPA for Kerberos-based single sign-on can each handle part of this flow. Test with a managed device and an unmanaged one to confirm the deny path. The output is a tested rule set and a test record showing the expected pass and block results.
Build the Coverage list of remote assets
Produce a list of every remote asset that reaches enterprise resources, matched against the asset inventory from step one. For each asset, record whether it uses the enterprise VPN and AAA, and list any that do not. The Coverage metric is the share of remote assets using VPN and AAA, so this list is the direct evidence behind it. Reconcile the list against the inventory each time it is produced. The output is a Coverage report with the numerator, denominator and an exception list.
Record exceptions in a register with owners and review dates
Any remote asset or device class that cannot use the enterprise VPN and AAA goes into an exception register, not a silent gap. Each entry names the asset, the reason, the compensating control, the accountable owner and a review date set by the organization. The register is reviewed by the risk owner and kept with the Coverage report. The output is an exception register that explains every item the Coverage metric excludes or counts as non-compliant.
Set a recurring compliance check and retain the evidence
Schedule a recurring check that re-runs the VPN Compliance, AAA Compliance and Coverage measures against the baseline, then records the results and any drift. Confirm the cadence with your own governance policy, since the assessment specification defines what to measure but not how often. Store configuration exports, Coverage reports, test records and exception decisions together so an independent assessor can trace each metric to its source. The output is a dated compliance record for each cycle that shows whether 12.7 still holds.

Evidence that shows Safeguard 12.7 is working

An assessor testing Safeguard 12.7 wants to see that remote devices reach enterprise resources only through the managed VPN and AAA path, and that the organization can prove it for the whole period under review. The six artifacts below map to the three CIS Assessment Specification metrics and to the prerequisite inventories, so each one can be pulled on a schedule rather than rebuilt before an audit.

VPN and AAA configuration exports

Scheduled exports of the VPN gateway, firewall rules and identity provider settings show which VPN profiles, authentication sources and access policies were active on each date. Assessors use these exports to score VPN Compliance and AAA Compliance, so check that each export shows the authentication backend, MFA requirement and the rule that blocks traffic from remote devices that bypass the VPN. Store exports with timestamps and a hash so they cannot be quietly edited.

Authentication logs before resource access

Logs from the VPN and the identity provider should show each remote session authenticating and receiving a tunnel before any enterprise application is reached. Pair the VPN session log with the application access log, matching on user and time, to confirm that resource access followed successful sign-in. Retain these logs for the period the assessor will sample, and confirm that failed and denied attempts are logged as well as successful ones.

Remote asset list reconciled to inventory

Coverage is the share of remote assets using VPN and AAA, so the denominator must be right. Export the list of end-user devices that connected remotely during the period and reconcile it against the detailed asset inventory required by Safeguard 1.1 and the software inventory from Safeguard 2.1, which the assessment specification names as prerequisites. Any remote device that appears in one list but not the other is a finding to resolve before the coverage figure is reported.

Compliance reports for each metric

Produce one report per metric: VPN Compliance, AAA Compliance and Coverage. Each report should state the population, the configuration baseline checked, the count of compliant and noncompliant items, and the date of the check. Ask whether the scanning or configuration tool that produces these reports is scheduled and whether its output is retained in the evidence store, since a one-time report cannot show that the control operated across the audit period.

Exception records with approvals

Some devices or users will need to reach resources without the standard VPN path, such as a contractor laptop that cannot run the client. Each exception should have a written reason, a named approver, an expiry date and a compensating control, such as restricted application access or an isolated network segment. Review open exceptions at each cycle and close those whose reason no longer applies, because an assessor will sample exceptions and check that approvals were in place when access was granted.

Change records for VPN and AAA settings

Every change to VPN profiles, encryption settings, authentication sources, MFA policy or group membership needs a ticket or commit that records who changed it, why and who approved it. Keep these alongside the configuration exports so an assessor can compare a setting in one export with the change that introduced it. Where settings are managed as code, the version history of the repository can serve as this record, provided reviews and approvals are enforced on merges.

What meeting Safeguard 12.7 costs in money and effort

This table lists the cost components of meeting Safeguard 12.7, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a request for a written scope so that quotes from any provider can be compared on the same components. No price figures are given because none are supplied for this safeguard.

Cost component	Who is paid	One-time or recurring	What drives it up or down
VPN and AAA licenses or support	Software vendor or subscription provider; or none for self-hosted open source	Recurring (subscriptions, support contracts); one-time for perpetual licenses	Up: number of named remote users and gateways. Down: reusing the AAA service already centralized under 12.5, and self-hosted open-source components that remove license spend but not staff time
Engineering time to configure VPN and AAA	Internal staff or implementation partner, under a written scope	One-time, with later change work	Up: number of remote device types, legacy AAA integrations, and gateways to harden. Down: standard device profiles and one identity source
Reconciling asset and software inventories	Internal staff or implementation partner	Recurring as devices and software change	Up: unmanaged personal devices and weak inventories under Safeguards 1.1 and 2.1, which are prerequisites for measuring 12.7. Down: enforced enrollment before VPN access
Evidence upkeep for the three metrics	Internal compliance or security staff	Recurring, typically per review cycle	Up: manual exports of VPN configuration, AAA settings and coverage data. Down: scripted exports and retained configuration history
External testing or review of the VPN configuration	Independent security testing provider or assessor, under a written scope	Recurring if repeated on a set cycle; one-time for an initial review	Up: number of gateways, custom remote access paths, and the depth of testing requested. Down: a narrow scope tied to the configured VPN and AAA services
Auditor sampling and testing	Independent auditor or certification body, under its own engagement terms	Recurring with each audit cycle	Up: number of remote device populations, sample sizes, and missing evidence. Down: a clear evidence package that maps each metric to its source data

Open-source tools that support Safeguard 12.7 evidence

Can OPNsense produce evidence for VPN rules under Safeguard 12.7?

OPNsense is a stateful packet filter, so it can show which traffic is passed, blocked or rejected for remote access paths, based on source, destination, port and protocol. Its rules can use aliases for address groups, which keeps remote-access policy readable for an assessor. Each rule can be set to log matches, and those entries appear in the live log view for review. That log trail helps show that remote traffic reaches enterprise resources only through the controlled path. It does not, by itself, prove that users authenticated. Confirm the VPN server options, client configuration and supported VPN protocols with the OPNsense vendor and its documentation before relying on them for the VPN Compliance metric. The license is BSD-2-Clause, which permits use and modification but carries no support obligation, so budget for internal or partner operations.

How does authentik support authentication evidence for remote access?

authentik is an identity provider that applications use to delegate sign-in. It supports OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so connected services can authenticate users against one central source. For Safeguard 12.7, this central authentication record is the kind of evidence that supports the AAA Compliance metric, which measures properly configured AAA services. Its logs and provider configuration can show which applications require sign-in and how. Whether a given VPN gateway or network device can use authentik through RADIUS or LDAP depends on that device, so confirm the specific integration with the authentik documentation and the gateway vendor. authentik is released under the MIT license. The main cost is the one-time design, deployment and testing effort, plus ongoing operations, which a fixed-scope implementation partner can prepare.

What does FreeIPA add for single sign-on on Linux and UNIX?

FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos key distribution center. It centralizes identities for those hosts, so administrators can show one place where access to Linux and UNIX systems is granted and managed. That supports the centralized AAA expectations in Safeguard 12.5, which Safeguard 12.7 lists as a prerequisite. FreeIPA is not a VPN, so it does not by itself show that remote devices connect through the VPN before reaching resources. Pair it with a VPN gateway and confirm, with the FreeIPA project and your VPN vendor, how authentication requests flow between them. FreeIPA is licensed under GPL-3.0-or-later, so review how the license applies to any modifications you distribute, and get legal advice where needed.

Is Coraza a VPN or an AAA service for remote devices?

No. Coraza is a web application firewall, not a VPN or an AAA service, and it does not provide either capability for Safeguard 12.7. It is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and it is designed to defend web applications against attacks such as SQL injection, cross-site scripting and code injection. It integrates with Caddy, HAProxy, Traefik and Nginx. Its use case is limited to web-facing portals that remote users reach, where it can help protect the application layer behind sign-in. Coraza is released under the Apache-2.0 license. Its logs can support application security evidence, but they do not show that a remote device used a VPN or passed AAA checks. Use it alongside, not in place of, a VPN and central authentication.

Which evidence should I collect from these tools for an assessor?

Assessors look for records that tie each measured item to a configuration and an outcome. For the three Safeguard 12.7 metrics, collect the following:

VPN Compliance: exported VPN and firewall configurations, rule sets with aliases, and change records for the VPN devices and software.
AAA Compliance: authentik or FreeIPA provider configurations, authentication logs and records of the RADIUS or LDAP links to network access systems.
Coraza or other web protections: rule versions and logs for protected portals.

For Coverage, you also need the asset inventory from Safeguards 1.1 and 2.1 to show which remote devices are in scope. Keep dated exports, because a single screenshot rarely satisfies an assessor. Ask your assessor which format and retention period they accept before you start collecting.

Who handles VPN and AAA setup if we use these tools?

The organization owns the control. It decides which remote devices must use the VPN, which services require sign-in, and who approves changes. An implementation partner can plan, install, configure, integrate and document these tools inside your own cloud accounts, data centers or air-gapped network, and prepare the configuration exports and logs that show the result. Under a fixed-scope agreement, the scope, deliverables and timeline are set in writing before work starts. Only an independent auditor or assessor can test the control and issue a report or certification. Ask any partner to state which parts of the VPN and AAA design they will deliver and which remain your responsibility.

Who does the Safeguard 12.7 work: your team, a partner and the auditor

Your organization owns Safeguard 12.7. That means the requirement that users on end-user devices authenticate to enterprise-managed VPN and authentication services before reaching enterprise resources is your decision, documented in your own policy and accepted by your leadership. No partner or auditor can take that ownership over.

Access policy: Write and approve the remote access standard that says which devices and user groups must use the VPN and AAA path, and which resources they may reach.
Exceptions: Decide which devices or users may be excluded, record the reason, set an approver and set a review date for each exception.
Asset and software inputs: Keep the detailed asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1) current, because the assessment specification lists them as prerequisites for measuring 12.7.
Sign-off: Review the coverage and compliance figures, accept the residual gaps and assign remediation owners.
Operations: Run joiner, mover and leaver steps for remote access accounts.

Confirm with your auditor which evidence they expect you to retain as the owner, and make sure your policy names the person who signs it off.

Common gaps that fail Safeguard 12.7 and how to close them

Most failures against Safeguard 12.7 come from the gap between what the policy says and what the enterprise can prove about remote devices. The cards below cover the gaps assessors most often find, and each one names the closing action that produces evidence an assessor can test.

Remote devices reachable without VPN

Some end-user devices reach internal applications directly over the internet, through published web services or legacy remote desktop gateways that skip the enterprise VPN and its authentication path. Safeguard 12.7 asks that users authenticate to enterprise-managed VPN and authentication services before reaching enterprise resources, so every such path is a finding. Check firewall and reverse proxy rules for inbound routes to internal services that do not terminate at the VPN. Close each route by moving it behind the VPN or an authenticated proxy, then keep the rule export as evidence.

AAA not centralized for 12.5

Remote access may authenticate against local VPN accounts or separate directories for each gateway, which leaves AAA Compliance unmeasurable. Safeguard 12.7 lists Safeguard 12.5 as a prerequisite, so the enterprise must show that authentication, authorization and auditing for remote access run through one central service. Inventory every VPN gateway and application that accepts logins, then point each one at the same identity provider or directory. Record the configuration of each integration so that the AAA Compliance share can be calculated.

Coverage calculated from incomplete asset list

The Coverage metric divides remote assets using VPN and AAA by the remote assets the enterprise knows about. If the asset list omits laptops enrolled under older projects, contractor machines or phones used for mail, the reported coverage is inflated. Safeguard 12.7 depends on Safeguard 1.1, so the denominator must come from the detailed enterprise asset inventory. Reconcile the remote access logs against the inventory each quarter, and investigate any device that connects without a matching inventory record.

Unmanaged personal devices without exceptions

Personal laptops and phones often reach enterprise mail or file shares with no VPN enrollment and no documented decision to allow them. An assessor will ask whether each remote device is either protected by VPN and AAA or covered by an approved exception with an owner and an end date. Write an exception process that names who approves access, which devices qualify and how exceptions expire. Then block unenrolled devices from reaching the resources that the exception process does not cover.

VPN configuration drift without change records

Cipher suites, split tunneling settings, certificate lifetimes and client profiles change over time, often during urgent troubleshooting. Without change records, the VPN Compliance metric cannot show that each gateway matches the approved configuration. Keep the VPN configuration under version control, and require a ticket or merge request for each change. Compare the running configuration against the approved baseline on a schedule and record the result.

No evidence trail for authentication

Teams often can say that users must sign in, but cannot produce logs showing which accounts authenticated, from which devices, and whether the attempt succeeded. Safeguard 12.7 is tested through measured compliance, so the enterprise needs records that a tester can sample. Enable logging for VPN sessions and identity provider sign-ins, forward them to a central store, and retain them long enough for the assessment period. Test the trail by picking a sample of remote sessions and tracing each one to a device record.

Questions buyers ask about Safeguard 12.7 cost, effort and outsourcing

Does Safeguard 12.7 apply to an IG1 organization?

No. CIS Controls v8.1 places Safeguard 12.7 in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. IG1 is CIS's essential cyber hygiene baseline and does not include this Safeguard. An IG1 organization that already gives remote users access through a VPN should still confirm that its configuration and authentication are sound, but it is not measured against 12.7 under the CIS Controls. If your organization sits between IG1 and IG2, confirm the Implementation Group you are assessed against with your auditor or customer before scoping the work, because contracts sometimes reference the Controls without naming a group.

How much effort does Safeguard 12.7 take, and what drives it?

The effort depends on how many remote devices and access paths you have, how much of the VPN and authentication stack already exists, and how well your asset and software inventories are maintained. Safeguard 12.7 is measured against the inventory work in Safeguards 1.1 and 2.1 and the centralized AAA work in 12.5, so gaps there add effort before 12.7 itself starts. The main cost drivers are:

The number of VPN gateways, firewalls and identity providers that need configuration review.
The number of end-user device types and operating systems that must authenticate.
Whether authentication is already centralized or split across local accounts and applications.
The depth of evidence your assessor expects, such as configuration exports and sign-in logs.

Ask any provider to show how each driver is priced in a written, fixed scope.

Can an in-house team implement Safeguard 12.7 without outside help?

Often yes, if the team already runs VPN and identity infrastructure and has clear ownership of both. The hard part is rarely the setup itself. It is keeping VPN and AAA configurations compliant over time, producing repeatable evidence and covering every remote device, including devices outside normal management. A team should be able to answer three questions before deciding: who owns the VPN gateways and the identity provider, who checks configuration drift each month, and who produces the coverage report. If any answer is unclear, the work will stall. Outside help is usually most useful for a fixed-scope readiness review, a configuration baseline or an evidence pack, while the organization keeps ownership of its controls.

What does Safeguard 12.7 need from our own staff?

It needs named owners from network, identity and endpoint teams who can make decisions and provide access. Network engineers must share VPN and firewall configurations. Identity staff must confirm which directory and authentication services are authoritative and how they are monitored. Endpoint or desktop teams must confirm which devices are managed and how remote devices are enrolled. Security or compliance staff should agree the evidence format early so that exports are produced once and reused. Because Safeguard 12.7 depends on Safeguards 1.1, 2.1 and 12.5, asset and software owners also need time to supply accurate inventories. Ask any partner to list these roles and time commitments in the written scope.

Which parts of Safeguard 12.7 are usually outsourced?

Organizations most often outsource the parts that need specialist time or independent review. Common examples include a gap assessment against the CIS Controls Assessment Specification, configuration hardening of VPN and identity platforms, building an evidence pack for the three metrics, and testing the remote access path. Keep ownership of control decisions, risk acceptance and policy approval in-house. An implementation partner such as DeployOpen can plan, implement, harden, integrate and document self-hosted platforms inside your own environment and prepare evidence. Only an independent auditor or assessor can issue a report or certificate, so the assessor should be engaged separately and early.

How does an assessor measure Coverage for Safeguard 12.7?

The CIS Controls Assessment Specification scores 12.7 with three metrics: VPN Compliance, AAA Compliance and Coverage. Coverage is the share of remote assets that use VPN and AAA. To measure it, an assessor compares the population of remote assets with the population that authenticates through the enterprise VPN and AAA services. That means your asset inventory must list remote devices, and your logs must show which devices authenticated and which did not. Expect the assessor to ask how you identify devices that reach enterprise resources without using the VPN, and how you handle exceptions. Confirm the exact measurement steps with the current specification and your assessor, since the specification defines what to measure but not how to collect the data.

What should we ask a provider for in a quote for Safeguard 12.7?

Ask for a written scope that names each deliverable, the systems in scope, the Safeguards it depends on and the client responsibilities. A useful quote separates one-time work, such as baseline configuration, integration and evidence design, from recurring work, such as monitoring, patch management and periodic coverage reporting. Ask which VPN and identity platforms are included, how remote devices are enumerated, what the handover includes and what happens if inventory gaps are found during work. Ask how changes after the engagement are priced and whether ongoing support is offered as a retainer. Compare quotes on this basis rather than on headline totals.

How DeployOpen scopes, implements and prepares evidence for Safeguard 12.7

DeployOpen plans, implements and documents the self-hosted platforms behind remote device VPN and AAA inside your own infrastructure, so the organization can show that remote devices reach enterprise resources only after authenticating to managed services. DeployOpen prepares systems and evidence; your organization owns the control, and an independent assessor reaches any conclusion about it.

How we scope

Written scope names the remote device population, VPN and AAA services, and the enterprise resources they must reach.
Scope confirms the prerequisite inventories for Safeguards 1.1, 2.1 and 12.5 exist or are planned before build work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

Configure a self-hosted VPN gateway and OPNsense rules so only managed devices reach enterprise networks.
Integrate authentik or FreeIPA so remote sign-in is centralized, logged and tied to enterprise identities.
Test VPN and AAA configurations against your own baseline, recording any gaps for remediation before handover.

How we hand over

Deliver configuration records and reports that show VPN Compliance, AAA Compliance and Coverage measurements for your assessor.
Document the process, roles and change records that show the safeguard is maintained, not only set up once.
Confirm with your assessor which evidence formats and sampling they expect before the handover package is finalized.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover re-measuring VPN and AAA coverage as new remote devices and services are added.
Ask any provider to confirm in writing which tasks belong to the scope, the retainer and your internal team.