What Safeguard 12.5 centralized network AAA requires
Safeguard 12.5 asks the enterprise to centralize network authentication, authorization and auditing (AAA), so that people who sign in to network devices are checked against one authority, what they are allowed to do is decided in one place, and their activity is recorded in one place. It applies to IG2 and IG3 enterprises, not IG1. For a network team facing an assessment, the question is whether administrator access to routers, switches, firewalls and wireless controllers flows through central services or whether each device still keeps its own user list.
The risk with local device accounts is simple. Each switch or firewall with its own administrator password is a separate place to create, forget, share or fail to remove an account, and a separate log that someone must remember to read. When an engineer leaves, the account may survive on forty devices. When a change breaks a segment, the logs may not show which login made it. Centralized AAA lets the team disable one identity and revoke access everywhere, and it lets reviewers see every administrative session and configuration change against a named user. Keep a local break-glass account, but control, monitor and document it separately.
Three things usually make this hard. The first is device count: many enterprises have network equipment that is not on any inventory, which makes the assessed Network Coverage share difficult to state honestly. The second is legacy equipment that supports only local accounts or old protocols, so it needs either a replacement plan or a documented exception. The third is shared accounts, such as a single admin login used by a contractor team. Before measuring anything, confirm that the software inventory under Safeguard 2.1 is complete, because the assessment treats it as a prerequisite. Ask your network vendor which AAA protocols each model supports and which accounts remain local by design.
Which network devices and access paths Safeguard 12.5 covers
Safeguard 12.5 applies to the network devices and access paths an administrator or user can reach, not only to the core routers. The cards below list the components an assessor will expect to see inside the AAA boundary and the scoping decisions that change how much work centralization requires.
Routers, switches and firewalls
These are the core network devices whose administrative logins and configuration changes must be authenticated and logged centrally. Build an inventory that lists each device, its management method and whether it authenticates against the central service. Check the exceptions too, such as a local emergency account that still exists on a switch. The Centralized AAA metric counts how many of these devices use the central service, so every unlisted device lowers the score.
Wireless controllers and access points
Wireless controllers hold administrator access and often authenticate end users, so they belong in scope for both administrative and user access. Confirm whether access points are managed through the controller or individually, because that decides where authentication is enforced. Record which wireless management accounts are local and which use the central directory. Wireless infrastructure is frequently overlooked during scoping, which makes it a common gap in the Network Coverage metric.
Management interfaces and out-of-band networks
Out-of-band management networks carry console, baseboard management and device admin traffic, and they often run on separate switches with their own accounts. Decide whether they are in scope, then either route their logins through the central service or document why they are excluded. An out-of-band network left outside AAA is a path around every other control. Ask the assessor how exclusions will be justified and reviewed.
VPN concentrators and remote access
VPN concentrators authenticate remote users and can also hold administrator access, so they are both a user path and an admin path. Confirm that user sign-in and any administrator login to the concentrator use the central service rather than local accounts. Include the remote access paths that reach these devices, since a remote administrator who bypasses the VPN is a separate access route. Coordinate with Safeguard 12.7 so the two measures use the same identity source.
Vendor-managed and cloud network services
When a provider operates a device or a cloud network service, the enterprise may not control its local accounts. Read the contract and service documentation to learn whether the provider can federate with your directory, expose audit logs and separate administrator roles. Where federation is not possible, record the provider's access model as a risk and an exception. Ask providers for evidence of their own administrator logging, because your assessor will ask how those changes are traced.
Scoping decisions that change the work
IG1 enterprises are not in scope for Safeguard 12.5, which applies to IG2 and IG3 enterprises. Confirm your Implementation Group before scoping, and document why any device is excluded. Software inventory from Safeguard 2.1 is a prerequisite, so an incomplete software and device list will undercount both metrics. Early decisions on exclusions and inventory quality determine how much integration work follows.
How an assessor tests centralized AAA under the CIS specification
This table shows how the CIS Controls Assessment Specification approaches Safeguard 12.5, from the prerequisite software inventory through the two scoring metrics to the evidence an assessor would ask for. The specification defines what to measure, not how to measure it, so the reader should confirm test steps with the assessor and the CIS specification text before relying on them.
| Assessment element | What the assessor looks for | Where it usually fails |
|---|---|---|
| Prerequisite: Safeguard 2.1 | A software inventory covering the AAA servers, network management tools and identity services that handle device and administrator sign-in | Network management platforms or appliance web consoles are missing from the inventory, so the AAA scope is incomplete from the start |
| Metric: Centralized AAA | The share of AAA services that are properly centralized, meaning authentication, authorization and accounting run through a managed central service | Several devices still authenticate against local accounts or a separate server that nobody reviews |
| Metric: Network Coverage | The share of network infrastructure assets whose administrative access is managed through the central AAA service | Switches, wireless controllers or out-of-band management interfaces are left off the list because they were never counted as network assets |
| Device configuration evidence | Exported or sampled configurations showing AAA servers, fallback behavior and management access settings on a representative set of devices | Configurations show a RADIUS or TACACS+ server listed, but no restriction on local login when that server is unreachable |
| AAA server settings | Server policy showing which groups may log in to which devices, with privilege levels mapped to roles | Authorization rules are broad, so most administrators hold full privilege on every device |
| Account listings | Current lists of local accounts on network devices, with the justification for each one that remains | Shared or vendor default accounts remain enabled and are not in the central directory |
| Logs of administrator access and changes | Accounting records tying each login and configuration change to a named user and time, retained and reviewed | Logs stay on the device, roll over quickly, or do not record commands run after login |
| Common finding: local fallback accounts | A documented break-glass process with tightly limited local credentials, monitored and reviewed | A local administrator password is set once and shared across a fleet, so central control does not apply during an outage |
How to implement centralized network AAA step by step
This sequence moves network administration from local accounts on each device to one identity source, one authorization policy and one audit trail, with each step producing a record that an assessor can check against the Safeguard 12.5 measures.
Confirm the software inventory and device list
Start from the software inventory required by Safeguard 2.1, which the CIS Controls Assessment Specification names as a prerequisite for measuring Safeguard 12.5. Network administrators, with the asset owner, list every router, switch, firewall, wireless controller, load balancer and management console, noting the firmware version and whether each device can use an external authentication source. The output is a coverage register with one row per network device, a column for its AAA method (local, RADIUS, TACACS+ or LDAP where supported) and an owner. Confirm the device capabilities with each vendor, because support for a given protocol varies by model and firmware.
Select the central identity and AAA service
The organization, with its identity and network teams, chooses the service that will authenticate administrators and authorize their actions. Candidate components include an identity provider for web-based management consoles and a directory or RADIUS-capable service for device login, and the choice depends on which devices the register shows can use each protocol. Record the decision, the owner of the service and the high-availability design in the network architecture documentation. The output is an approved design record that names the central AAA service, its fallback path and the devices it covers.
Integrate device authentication and authorization
Engineers point each device at the central service in a staged order, starting with a non-production or lower-risk device so that a configuration mistake does not lock out every administrator. For each device they configure the external authentication method, the authorization mapping that assigns administrator roles from group membership, and the accounting target for session and command records. Changes should be made through version-controlled configuration where the platform supports it. The check that closes each device is a login test by a named administrator who is in the correct group and a denied test by a user who is not, both recorded in the coverage register.
Define role-based administrative privileges
Network and security leads define a small set of administrator roles, such as read-only operator, change engineer and security auditor, and map each role to the minimum commands or management functions it needs. Group membership in the central directory drives the mapping, so that access is granted and removed in one place and not on each device. The output is a role matrix that lists each role, the devices it applies to, the permitted actions and the approver for membership changes. Assessors look for this matrix when they test whether authorization is controlled centrally rather than by individual device settings.
Enable centralized audit logging
Engineers configure every integrated device to send authentication events, session starts and ends, and configuration or command changes to a central log store that administrators cannot quietly edit. They confirm the timestamps are synchronized so that events from different devices can be correlated, and they set alerts for failed logins and for changes made outside an approved change window. The output is a sample of events from each device showing a login, a denied attempt and a configuration change, traced through to the central store. This evidence supports the Safeguard 12.5 measures, and it links to the logging work in Control 8.
Remove or control local accounts
Once a device authenticates through the central service, the team removes its unneeded local administrator accounts or disables their password login, leaving at most one tightly controlled local account for recovery. Each remaining local account is recorded in the register with its owner, its storage location and its rotation procedure. Security staff confirm that the device still accepts a login through the central path after the change. The output is a register showing no unmanaged local administrators, with the retained recovery account listed as an exception.
Test and document the break-glass procedure
The team writes a break-glass procedure for the case where the central service is unavailable, describing who may use the recovery account, how the credential is stored and how its use is logged and reviewed afterward. They then run a controlled test in a planned window, confirm that access works through the recovery path and that the event reaches the central log store, and record the result. The output is a dated test record signed by the reviewer and the network owner. Ask your auditor or assessor what evidence they expect for the test, since the expectations for recovery testing vary by organization.
Measure coverage and keep the register current
The organization calculates the two measures in the CIS Controls Assessment Specification: the share of network devices using properly centralized AAA, and the share of network infrastructure assets managed through AAA. Both figures come from the coverage register, so the register must be reviewed when devices are added, replaced or upgraded. The output is a recurring coverage report with a named owner and a review step that compares the register against the software inventory and the device list. Without this step, the measures drift as new equipment arrives outside the process.
Why network coverage is the number assessors check first
Assessors check the Network Coverage metric first because it tells them whether the Centralized AAA score can be trusted at all. The Assessment Specification defines it as the share of network infrastructure assets managed through AAA, so the denominator is your list of network infrastructure assets. If that list is incomplete, a high centralization score can describe only the devices someone remembered to onboard. Before the AAA design is reviewed, the assessor will ask for the device register and compare it with the AAA records. Safeguard 2.1, the software inventory, is a stated prerequisite for measuring 12.5, so confirm that your software and platform inventory already covers the management planes of routers, switches, firewalls and wireless controllers.
Partial coverage usually appears in evidence as a gap between two lists. A device inventory that includes a switch or out-of-band management appliance, with no matching entry in the RADIUS or TACACS+ client list or the identity provider's authorization records, is the classic pattern. Local accounts that remain on a device after AAA is enabled, and admin sessions that log in with shared credentials, are also signs of partial coverage. Treat each unmatched asset as either a onboarding task or a documented exception with an owner and a date. Reconcile on a stable key such as the management IP address, hostname and serial number, and keep the reconciliation output with the period's evidence so the assessor can follow it.
Run the reconciliation as a repeatable check rather than a one-time clean-up. Export the network device register from your CMDB or inventory tool, export the client or NAS definitions from the AAA service, and export the authorization policies that map administrator groups to device privileges. Flag any device present in one list and absent from the other, then confirm whether the AAA service logs authentication and command events for each matched device. Illustratively, a firewall that answers management requests but is absent from the AAA client list would lower the Network Coverage figure until it is onboarded or formally excluded. Ask your implementation partner or internal team to document the query, the schedule and the person who signs off the result.
Evidence that proves network devices use centralized AAA
An assessor testing Safeguard 12.5 wants two things: proof that the AAA service exists and is configured centrally, and proof that every network device in scope actually relies on it. The cards below cover the artifacts that show both, and the routine that keeps them current between assessments.
AAA server configuration exports
Export the configuration of the central authentication, authorization and accounting service on a fixed schedule, and keep the dated copies. The export should show the user sources, the authorization policies that map groups to device privilege levels, and the accounting settings that record administrator sessions. Ask the assessor which export format and retention period they expect, and confirm the export includes the access policies rather than only the server settings. The export should be produced by a tool the organization controls.
Device configurations referencing AAA
Collect the running configuration from each network device and confirm it points to the central AAA service for login, command authorization and accounting. A device that keeps a local administrator account as its only login path fails the Centralized AAA metric even if the central service is healthy. Check that local fallback accounts, where they exist, are tied to a documented exception and are not used for routine administration.
The AAA coverage register
Maintain a register that lists every network infrastructure asset and whether it is managed through central AAA. This is the working document behind the Network Coverage metric, which measures the share of network infrastructure assets managed through AAA. The register depends on the software inventory required by Safeguard 2.1, so a device missing from the inventory will also be missing from coverage. Reconcile the register against discovery results before each assessment.
Authorization policy mappings
Document which directory groups receive which device roles, such as read-only monitoring, change operator or full administrator. Each mapping should trace to a named owner and an approved access request. Assessors use these mappings to test whether the authorization that AAA enforces matches the access the organization approved. Keep the mapping under version control so that a change to a role is visible as a dated diff.
Administrator access and change logs
Retain the accounting records from the AAA service and the device logs that show who logged in, which commands ran and when configuration changed. Forward these records to a central log store so they cannot be altered by the device administrator. Test a sample: pick a recent configuration change and confirm the log names the user, the device and the time. Retention periods for these logs should come from the organization's own policy and any regulation that applies to it.
Break-glass account records
Record every use of an emergency local account that bypasses central AAA, including who used it, why, the device affected and the approval or incident reference. Store the account credentials under dual control and rotate them after each use. Assessors look for these records to confirm that the exception path is rare, documented and reviewed, and that it is not quietly used for daily work.
Open-source platforms that support centralized AAA
authentik is an identity provider that can act as the central source of sign-in for applications and, through its provider types, for some network-facing services. It supports OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications and supporting services can delegate authentication to it instead of keeping local accounts. For Safeguard 12.5, the useful evidence is a configuration record showing which applications and services authenticate through the central provider, together with sign-in and authorization logs that show who accessed what and when.
- Provider coverage: an inventory of each application or service bound to an authentik provider, which feeds the Network Coverage metric when those services are network infrastructure management tools.
- RADIUS and LDAP providers: the relevant route for devices or services that accept those protocols, if your hardware supports them.
- Proxy providers: protect web-based administration interfaces that lack native SSO.
- Event logs: sign-in and authorization events that can be forwarded to a central log store.
- Limit: authentik does not itself log commands typed on a switch or router unless the device sends its AAA requests to it.
Confirm with your hardware vendor whether its management plane supports RADIUS or TACACS+ for login and command authorization, and document the result in your Safeguard 12.5 evidence.
FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos key distribution center (KDC), along with a central directory of users, groups and host identities. It is most relevant where administrators reach Linux-based management hosts, jump servers, or the appliances that run network management software. Its evidence is the central identity record and the Kerberos ticket activity that shows administrators authenticating against one source, rather than a per-host password file.
- Central identity store: one directory of administrator accounts and groups that management hosts consult.
- Kerberos SSO: administrators obtain tickets from the KDC instead of entering local passwords on each host.
- Host enrollment records: a list of enrolled hosts that supports the asset coverage question in the metric.
- Access rules: host-based access controls that restrict which groups can reach which systems.
- Limit: FreeIPA covers Linux and UNIX logins. It does not authenticate proprietary network operating systems on routers or switches, so those devices need a separate AAA path.
License check: FreeIPA is licensed under GPL-3.0-or-later. Review what that license requires for your modifications and distribution before you embed it in a product or appliance.
OPNsense is a stateful packet filter, and its rules pass, block or reject traffic by source, destination, port and protocol. Aliases group addresses so that rules stay readable across many segments. Its contribution to Safeguard 12.5 is evidence about who can reach the management network and what was permitted or denied, not evidence of administrator logins to devices. Enabling per-rule logging lets you review matches in the live log view and export them to a central store.
- Rule set: the approved list of sources and destinations allowed to reach management interfaces, documented with aliases.
- Per-rule logging: a log entry for each match, which shows that access to administrative ports was allowed or blocked.
- Live log view: a way to review recent matches during an investigation or assessment walkthrough.
- Alias records: exported alias definitions that show how management address groups are defined and maintained.
- Limit: rule logs show network flows. They do not show which named administrator authenticated, so pair them with AAA logs from the identity components.
OPNsense is licensed under BSD-2-Clause. Confirm the current logging and export options in the OPNsense documentation for your version before you design the evidence collection.
Centralized AAA for network devices depends on what each device can send to a central service. Open-source identity and firewall components can cover applications, Linux management hosts and traffic policy, but a switch or router that only supports local accounts will still fall outside the Network Coverage metric. The gap is usually found during asset review, so it helps to test it before writing the evidence.
- Device inventory: list every network device and record whether it supports RADIUS, TACACS+ or another central method for login and command authorization.
- Vendor confirmation: ask each hardware vendor in writing which AAA protocols its management plane supports, and whether command authorization and accounting are included.
- Fallback accounts: document how local emergency accounts are controlled, stored and logged where a device cannot use central AAA.
- Log correlation: confirm that identity events, firewall logs and device logs share time synchronization so that a single administrative session can be traced.
- Scope statement: record which devices are inside the AAA scope and which are excluded, with the reason.
Before relying on any component for Safeguard 12.5, confirm its current features and license terms with the vendor, project or your own environment.
What meeting Safeguard 12.5 costs in money and effort
Meeting Safeguard 12.5 is mostly an engineering and operations cost, not a license cost. The organization pays for engineers who connect each network device, firewall and management interface to a central AAA service, for hosting that service, and for the people who reconcile the device inventory against the AAA records and run access reviews. Self-hosted open-source components such as authentik, which can act as an identity provider over RADIUS and LDAP, or FreeIPA for Linux administration, remove license spend, but the integration work, testing and upkeep still need paid people. Ask any partner or internal team to price these items separately so that the software line does not hide the labor line.
Separate the one-time work from the recurring work. The one-time portion covers designing the AAA architecture, deciding which device classes authenticate centrally, configuring each device's authentication and authorization settings, enabling audit logging of administrator sessions and configuration changes, and proving the coverage baseline. The recurring portion covers reconciling the list of network assets against what authenticates through AAA, reviewing administrator accounts and role assignments, keeping the identity platform patched and backed up, and producing the evidence that the Centralized AAA and Network Coverage metrics in the assessment specification require. Confirm with your assessor which evidence window they will sample, because that sets how much recurring evidence upkeep you must fund. Safeguard 2.1, the software inventory, is a prerequisite, so its upkeep belongs in the same budget.
The main cost drivers are device count, vendor diversity and the number of legacy devices that cannot use centralized authentication. Each additional firewall model, switch family or management appliance usually means another configuration path and another test case. Devices that only support local accounts may need compensating controls and a documented exception, which adds review effort every cycle. External review, whether an independent assessor's sampling or a second line review by your own compliance team, scales with the number of devices and changes in scope. When requesting a quote, ask for the work broken out by device group, the assumed evidence period, the number of access reviews per year and who owns ongoing reconciliation after the engagement ends.
Who owns, implements and assesses Safeguard 12.5
The enterprise owns Safeguard 12.5. CIS Controls are a set of safeguards the organization itself must implement and maintain, so the decision to centralize network AAA, the accountable executive, and the operating process all sit inside the organization. In practice the work usually falls to the network team and the identity team together, with security governance setting the policy that every network device must authenticate and log administrator actions through a central service.
- Named accountable owner: A single role, often the head of network or the CISO's delegate, signs off on scope, exceptions and the metrics reported to leadership.
- Asset and device ownership: The network team maintains the list of switches, routers, firewalls and wireless controllers that fall under Network Coverage.
- Policy and exception handling: Devices that cannot use central AAA need a documented, time-limited exception with a compensating control.
- Operational review: Someone internal reviews AAA logs and failed logins on a defined cadence.
- Dependency on Safeguard 2.1: The software inventory is a prerequisite for measuring this Safeguard, so the asset owner must keep it current.
Confirm internally which team holds each of these responsibilities before any outside party is engaged, because the assessor will ask the organization, not the partner, to explain them.
An implementation partner such as DeployOpen works under a written, fixed scope to prepare systems, configuration and evidence. For this Safeguard that typically means deploying a self-hosted identity provider, connecting network-facing services to it, and producing the records an assessor will sample. The partner does not decide whether the organization meets the Safeguard and does not sign any conclusion about it.
- Integration work: Connecting identity sources, directory services and authentication protocols such as RADIUS or LDAP to network and application access points, using a platform like authentik or FreeIPA where the organization has chosen them.
- Configuration preparation: Documenting the AAA settings, authorization groups and logging destinations in a form the organization can review and maintain.
- Evidence preparation: Exporting device lists, authentication logs and change records so the Centralized AAA and Network Coverage metrics can be calculated from them.
- Hardening and backup: Securing the identity service itself, since a compromised AAA server would undermine every device behind it.
- Handover documentation: Runbooks that let the internal team operate and audit the setup after the engagement ends.
Ask for the written scope to name each deliverable and state that the organization retains ownership of the control outcome.
An independent auditor, assessor or certification body tests whether the Safeguard is implemented and issues any report or certificate. Under the CIS Controls Assessment Specification, the assessor measures the Centralized AAA and Network Coverage metrics against the evidence the organization presents. Only the assessor's own testing and conclusions carry weight in a formal assessment.
- Sampling and testing: The assessor selects devices, reviews their AAA configuration and checks authentication logs against the claimed coverage.
- Evidence independence: Evidence prepared by an implementation partner is an input the assessor may test, not a result the assessor accepts on trust.
- Conflict limits: An assessor who designed or configured the environment generally cannot also certify it. Confirm each firm's independence rules before hiring.
- Reporting: Only the assessor or certification body issues a report, attestation or certificate. DeployOpen does not issue audit reports, attestations or certifications.
- Accreditation questions: Where CIS Controls Accreditation applies, confirm the firm's status directly with CIS before relying on it.
Ask any assessor to describe in writing which activities they would perform and which they would not perform for you.
Most organizations outsource part of the build and evidence work, not the ownership. The usual split is that the partner handles integration, configuration and evidence preparation, while the internal team keeps policy, device inventory accuracy, exception approval and log review. Outsourcing a larger share of operation does not transfer accountability for the control.
- Typically outsourced: Identity platform deployment, protocol integration with network devices and applications, initial hardening, and generation of evidence exports.
- Usually retained internally: The policy decision, the authoritative asset list, the exception register and the ongoing review of AAA logs.
- Shared activities: Testing of changes before production, and the handover of runbooks so the internal team can operate the service.
- Cost drivers: The number of network device types, the number of protocols to integrate, and whether the environment is single site or distributed. Ask the partner to tie each cost to a line item in the written scope.
- Recurring work: Patching the identity service, reviewing access groups and retaining logs for assessment periods. Confirm whether support is a separate retainer.
Before signing, ask which deliverables are one-time and which recur, and who performs each.
Common gaps that fail centralized AAA reviews
Most Safeguard 12.5 findings come from a few recurring gaps: device accounts that bypass the central service, logs that stop short of the AAA layer, and inventories that do not show what should be covered. Each card names one gap, how to close it, and the evidence that shows it is closed.
Local admin accounts left on switches
Switches, routers and firewalls often ship with local administrator accounts that keep working even after the central AAA service is live. Any local login path is a route around the central service and lowers the Centralized AAA score. Disable or restrict local accounts on each device, keep one tightly controlled emergency credential, and confirm with a sample of devices that a central login is the only routine path. Evidence: device configuration exports showing local accounts removed or locked, and a reconciliation of device login methods against the central directory.
AAA servers without audit logging
A central AAA service that authenticates administrators but does not record who logged in, from where and what they changed only moves the blind spot. Auditing is part of the AAA function that Safeguard 12.5 names, so the AAA server, its directory and the network devices should all send authentication and authorization events to a central log store. Check that accept, reject and command events are captured and retained. Evidence: log source inventory, sample authentication records with timestamps and device names, and retention settings.
No break-glass procedure
When the AAA service or its identity provider is unavailable, administrators may resort to shared or undocumented local accounts. A break-glass procedure defines who may use an emergency credential, how it is stored, when it is used and how each use is reviewed afterward. Without it, the emergency path becomes the normal path. Confirm that the credential is sealed, that use triggers an alert, and that every use is reviewed against a ticket. Evidence: the written procedure, a sealed-credential custody record, and records of past break-glass uses with their reviews.
Incomplete device coverage
Network Coverage measures the share of network infrastructure assets managed through AAA, so every device left on local accounts drags the score down. Coverage gaps often sit in out-of-band management interfaces, wireless controllers, branch equipment and lab hardware that were never added to the AAA configuration. Compare the device inventory with the list of devices that authenticate centrally and resolve each difference. Evidence: a reconciled coverage report showing managed and unmanaged devices, with dated remediation entries for each exception.
Missing software inventory
Safeguard 2.1 is a prerequisite for measuring Safeguard 12.5, so the assessment expects a current software inventory to show which network operating systems and management tools exist and which of them support centralized AAA. Without that inventory, teams cannot prove which platforms were configured, which versions lack support for the AAA method in use, or where an older agent still accepts local logins. Build the inventory from discovery data, tag each network platform with its AAA capability, and review it on a set schedule. Evidence: the software inventory export filtered to network platforms, with AAA capability notes and review dates.
Safeguard 12.5 questions buyers ask before hiring help
Does Safeguard 12.5 apply to IG1 organizations?
No. Safeguard 12.5 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises. IG1 is the essential cyber hygiene baseline that CIS sets as a minimum for every enterprise, and it does not include this safeguard. If you are IG1 but a customer contract, regulator or sector scheme asks for centralized network AAA, that obligation comes from the contract or scheme, and the CIS Controls do not replace it. Confirm your Implementation Group against the CIS Implementation Groups pages, then check your own complexity and the sensitivity of the data you hold, since those factors decide whether IG2 expectations apply to you.
How long does centralizing network AAA usually take?
No standard duration for this safeguard is published, so treat any number you hear as a question to put to the provider. Duration depends on the number of network devices, how many use centralized authentication today, the quality of your identity source, the software inventory that Safeguard 2.1 requires as a prerequisite, change windows and testing time. Ask for milestones in the written scope: inventory, a pilot device group, cutover of the remaining devices, and validation of authentication and audit logs. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so the schedule should follow from that scope rather than from an estimate made before discovery.
Can our own team centralize network AAA in-house?
Often yes, if your team already runs a directory service, administers network devices and manages logs. Check four things first: whether your directory is reliable and well governed, whether each device model supports centralized authentication and command authorization, whether you can test a fallback path without locking administrators out, and whether someone owns the audit trail. Open-source identity platforms can cover much of the work. authentik supports RADIUS and LDAP among its provider types, and FreeIPA provides single sign-on for Linux and UNIX environments. Confirm device support for each protocol before you commit to a design, because the protocol a device supports often decides the architecture.
What does the work need from our team?
The work needs named owners more than it needs large amounts of time. You will need an owner for the AAA policy, a directory administrator, owners for each device group who can approve configuration changes, a change board that accepts maintenance windows, and someone who can retain authentication and administrative logs. Your team also needs read access to current device configurations for the inventory and any test accounts needed for validation. DeployOpen plans, implements and documents systems inside your environment, but your organization keeps ownership of the controls, the policy and the decisions. Ask the provider for a responsibility matrix that lists who does each task before the scope is signed.
Can a partner issue the CIS Controls assessment for Safeguard 12.5?
No. An implementation partner prepares systems, configuration and evidence, but only an independent assessor or certification body issues reports or certificates. CIS Controls do not have a certificate that a partner can issue for a single safeguard. If you need an independent view, ask whether the assessor holds CIS Controls Accreditation, which CIS runs with CREST for SecureSuite member organizations that provide implementation, auditing or assessment services. Accreditation shows the organization is recognized for that work, but it does not replace your own internal assessment or any regulatory audit your sector requires. Confirm the scope, the assessor's credentials and the report type in writing before the work starts.
How does the CIS assessment measure Safeguard 12.5?
The CIS Controls Assessment Specification scores Safeguard 12.5 with two metrics. Centralized AAA measures the share of network AAA services that are properly centralized. Network Coverage measures the share of network infrastructure assets managed through AAA. Those metrics tell an assessor what to measure, and the specification does not prescribe how your team should collect the data. Evidence usually includes a device inventory showing which assets authenticate centrally, configuration exports showing the AAA server for each device, authentication and command logs, and a register of exceptions with owners and dates. Build your evidence so that each metric can be recalculated from the inventory without manual reconstruction.
Which open-source tools support centralized network AAA?
Several open-source components can support different parts of the design. authentik (MIT) acts as an identity provider through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications and some network services can delegate sign-in to it. FreeIPA (GPL-3.0-or-later) provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. OPNsense (BSD-2-Clause) can log each firewall rule match for review in its live log view, which supports the audit side of the safeguard. Each component has its own licensing terms, so have legal review them before you deploy, and confirm that each device in your network can use the protocol the chosen tool exposes.
What drives the cost of centralizing network AAA?
Cost has three parts: the people who inventory and integrate devices, the platform that holds identities, and the testing and evidence work that proves the metrics. Open-source software removes license fees for the components, but labor, hosting and support remain. One-time costs include discovery, design, integration, testing and documentation. Recurring costs include operating the identity platform, reviewing exceptions, rotating credentials and maintaining the evidence set. Costs rise with device variety, the number of separate directories, and the amount of manual configuration. When you request a quote, ask for the written scope, the separate one-time and recurring line items, the assumptions about device count, and whether ongoing support is a retainer.
How DeployOpen prepares centralized AAA evidence
DeployOpen's part in Safeguard 12.5 starts with a written scope that names every network device, management interface and access path that will be brought under centralized AAA. The scope lists administrator roles, the directory or identity source each role signs in through, and the devices that will authenticate through RADIUS or TACACS-style services. The Assessment Specification ties this work to the software inventory in Safeguard 2.1, so the scope should also reference the inventory records that identify each device's software. The organization owns the inventory and the decisions about who may administer which device. DeployOpen's job is to document the scope, agree it in writing with the client, and then implement against it, so the denominator behind the Network Coverage metric is visible before any build begins. Confirm with your assessor how they expect unmanaged or out-of-band devices to be counted.
DeployOpen then implements the integration inside your own environment, in your cloud accounts, data centers or air-gapped network. Typical work includes connecting network device administration to a self-hosted identity provider such as authentik, which supports LDAP and RADIUS provider types, and federating Linux and UNIX administrator logins through FreeIPA's Kerberos-based single sign-on where that fits your estate. Device-side configuration, group-to-role mapping, break-glass accounts and audit logging of administrator sessions are each recorded as configuration items. Where a change is made locally on a firewall such as OPNsense, the rule set and its logging settings are part of what the evidence pack must show. Confirm each target device's supported AAA options with its vendor before committing to a design, because not every platform supports every protocol.
DeployOpen prepares an evidence pack for your assessor. It typically holds the signed scope, the device and account reconciliation showing the Centralized AAA and Network Coverage figures, sample authentication and authorization records, change logs for AAA configuration, and records of access reviews. DeployOpen does not issue audit reports, attestations or certifications. The organization decides which evidence to present, and an independent assessor tests it and forms the conclusion. Retainers can cover ongoing reconciliation, so that new devices, retired accounts and role changes are added to the scope and the metrics stay current between assessments. Ask any provider to state in writing what the retainer covers, how reconciliation is recorded, and who approves changes to the scope.
