What Safeguard 6.6 asks for and why it is harder than it looks
If an auditor or a customer questionnaire asks which systems authenticate and authorize your users, Safeguard 6.6 is the requirement behind that question. It asks you to keep a maintained inventory of every system that signs users in or decides what they may do, whether you host it yourself or a remote service provider runs it, and to review that list at least once a year. The list is only useful if it is complete, so the hard part is rarely writing the document. It is finding the systems nobody remembered to record.
The usual gaps are predictable. A directory stood up for a pilot and never retired, an LDAP or Active Directory instance that a legacy application still binds to, a self-service portal with its own local user store, a SaaS tool that a team connected through a personal "Sign in with" account, and an administrative console on an appliance that was installed years ago and is still reachable. Each of these can hold credentials or grant rights outside your central controls. Safeguard 6.6 sits in the Software asset class and the Identify function, next to the software inventory (Safeguard 2.1), because you cannot judge the authentication path of an application you have not listed. The Assessment Specification treats 1.1 and 2.1 as prerequisites for measuring 6.6 for this reason.
Two points set expectations. Safeguard 6.6 is an IG2 and IG3 Safeguard, not IG1, so an enterprise that has only the IG1 set is not yet expected to meet it, although the inventory it supports is often useful earlier. CIS also states that the Assessment Specification describes what to measure, not how. In practice, confirm with your assessor how they will test completeness, for example by comparing your list against identity provider logs, DNS and network discovery results and the software inventory. The Specification scores the Safeguard as failing when no inventory exists or it was last updated more than 12 months ago, so set a review date and record each review.
Which identity systems fall in scope for 6.6
Safeguard 6.6 asks for a list of every system that authenticates or authorizes users, whether it runs in your data center or with a service provider. The cards below cover the kinds of system that belong on that list, the places where systems hide, and the scoping decisions that change how large the inventory becomes.
Directories and identity providers
Directories such as Active Directory or FreeIPA, and identity providers that issue tokens to applications, form the core of the inventory. Record each directory forest or realm, each identity provider tenant, and its owner. A directory that feeds several identity providers counts once as a source and again wherever it is consumed, so the entries should show those links. Check that no domain controller or realm exists outside the list.
SSO brokers and federation services
Single sign-on brokers sit between applications and directories and often hold their own configuration, signing keys and provider connections. Each broker is an authentication system in its own right, even when it only forwards requests. List the protocols it serves, such as OAuth2, OpenID Connect, SAML, LDAP, RADIUS or proxy, and the applications that depend on it. Losing a broker removes sign-in for every application behind it, which makes it a priority entry.
RADIUS, LDAP and MFA services
Network access servers, VPN concentrators, Wi-Fi controllers and MFA services each authenticate users against a backend, and many run outside the main identity platform. Record the service, the backend it queries, and whether it stores credentials or only relays them. Include MFA factors and push services, since an unlisted MFA service can grant access that the directory never sees. Confirm with network and security teams that the appliance list matches what is actually configured.
Authorization engines and application-local stores
Policy engines that decide what a user may do, and user tables inside applications, both control access even when they do not check passwords. An application with its own user database, admin role or API token scheme is an authentication system for this Safeguard. Ask development teams to report every application with local accounts, including internal tools, reporting platforms and vendor portals, and record which system holds the authoritative user record.
Service-provider and shadow sign-ons
Software-as-a-service products often run their own sign-in, and staff may create accounts with personal or team email addresses that IT never approved. Safeguard 6.6 covers systems run by remote service providers, so each one that authenticates your users belongs in the list. Use single sign-on logs, expense records, browser extension reports and identity provider application catalogs to find sign-ons that were never registered. Each discovered sign-on either joins the inventory or goes through the removal process.
Scoping decisions that change the size
Four decisions set how large the inventory becomes: which business units are included, which environments (production, test, development) are in scope, whether service accounts and API keys are recorded as systems or as accounts, and whether systems that only hold machine identities are included. Write each decision down with its owner and reason. Ask any assessor or consultant to confirm these choices in the scope statement before the inventory is built, so the list is not measured against a different boundary later.
How the CIS assessment tests Safeguard 6.6
This table sets out what the CIS Controls Assessment Specification checks for Safeguard 6.6, the evidence an assessor expects, and where organizations usually fall short. Read each row as a test step: the measure states the condition, and the evidence column shows what proves it. The main takeaway is that a complete, dated inventory that reconciles with the software and asset inventories matters more than the list alone.
| Test element | What the assessment looks for | Where organizations usually fall short |
|---|---|---|
| Pass or fail condition | Fails if no inventory of authentication and authorization systems exists, or if it was last updated more than 12 months ago | An inventory exists but has no date, so the assessor cannot confirm the 12-month window |
| Accuracy measure | Compares the systems listed as authorized with the systems actually recorded in the inventory | Authorized single sign-on or directory services are missing from the list |
| Inventory export | A current list showing each system, whether it is self-hosted or run by a service provider, and its owner | Entries name a product but not the hosting location or the responsible team |
| Review record | Evidence of a review at least once a year, such as dated meeting notes, a change ticket or a signed approval | Reviews happen informally with no record, or the review date is missing |
| Reconciliation with Safeguard 2.1 | Authentication and authorization applications appear in the software inventory and match its entries | Identity products installed as containers or SaaS tenants are missing from the software inventory |
| Reconciliation with Safeguard 1.1 | Identity servers and gateways appear in the enterprise asset inventory where they run on owned or managed hardware | Virtual machines or cloud resources hosting identity services are not tracked as assets |
| Vendor-hosted systems | SaaS identity providers, external single sign-on and provider-managed directories are listed with their service provider | Vendor-hosted systems are assumed to be out of scope and are left off the list |
| Ownership and change control | Each entry has a named owner and changes to authentication systems trigger an inventory update | New applications connect to the identity provider without anyone updating the list |
How to build the inventory in six steps
The sequence below turns Safeguard 6.6 from a sentence in a standard into a reviewed list of every system that decides who gets in and what they can do, with an owner and a review date for each entry.
Define what counts as an authentication or authorization system
Agree a written definition before anyone searches. It should cover systems that verify identity (directories, identity providers, SSO, MFA services, RADIUS or LDAP servers, Kerberos realms) and systems that decide permissions (application role stores, cloud IAM, privileged access tools, firewall or VPN user databases). Owners are the security lead and the identity team, and the output is a short approved definition with examples of in-scope and out-of-scope systems. You know it is done when two reviewers classify the same ten sample systems the same way.
Pull candidates from the software and asset inventories
Start from the software inventory built for Safeguard 2.1 and the enterprise asset inventory built for Safeguard 1.1. Filter both for identity-related products, server roles and hosted services, and add any entry where a login page or API key controls access. Software inventories are the most likely source of gaps because teams often adopt sign-in tools outside central procurement. The output is a candidate list with a source reference for each row. Done means every candidate traces back to a line in one of the two inventories.
Record owner, hosting, protocol and integrations for each system
For each candidate, capture the accountable owner, whether it runs on site or with a remote service provider, the authentication protocols it speaks (for example OAuth2, OpenID Connect, SAML, LDAP, RADIUS or Kerberos), and the applications or networks that depend on it. Owners complete the hosting and protocol fields, and the identity team checks integrations. Recording both self-hosted and provider-run systems is what the Safeguard asks for. Done means no row has a blank owner or hosting field.
Reconcile the list against SSO and directory logs
Compare the candidate list with what the environment actually does. Pull the sign-in sources from the identity provider, directory service and remote access gateways for a recent period, and check which systems appear there but not in your list. Systems that appear only in logs are the usual findings, such as a departmental sign-in service or an unregistered SaaS application. The output is a reconciliation record showing added, removed and confirmed systems. Done means every system seen in logs is either inventoried or formally excluded with a reason.
Set the annual review cadence and assign the reviewer
Name the person accountable for the inventory and set a review at least once a year, which is the interval the assessment specification uses when it scores this Safeguard. Confirm with your assessor how they will test the review date and whether they expect evidence of more frequent updates. The output is a documented review procedure, a calendar entry and a named reviewer. Done means the last-reviewed date is visible on the inventory itself.
Tie every change to change management
Require that adding, retiring or changing an authentication or authorization system updates the inventory as part of the change ticket, so the list does not drift between annual reviews. Connect the inventory to procurement for new sign-in services and to decommissioning for retired ones. The output is a change template field and a workflow rule. Done means a sample of recent changes shows matching inventory updates. This step also supports the 5.5 and 13.5 work described below.
Building the inventory with self-hosted open-source tooling
The inventory that Safeguard 6.6 asks for needs one place where the enterprise records each authentication and authorization system, whether it runs on its own servers or with a remote service provider. GLPI's Assets module can serve as the configuration management database or asset register for that list. It holds computers, software, network equipment and other items, and the GLPI Agent can push hardware and software data automatically through native inventory built into GLPI since version 10. Identity platforms are not always captured by that automatic data, so teams usually add them as records by hand.
- Record the service, not only the host: Capture each identity system, its owner, its hosting model and the applications that rely on it.
- Include provider-run services: Add SaaS identity providers and their administrative consoles, with the contract or account owner named.
- Track the review date: Store a last-reviewed field so the annual update the Safeguard describes can be shown on request.
- Link records to dependencies: Connect each identity system to the applications it serves, which helps the accuracy comparison.
- Confirm import behavior: Check in your own environment which fields the automatic inventory fills and which need manual entry.
Before relying on the register, confirm with your GLPI version and configuration how it handles custom asset types and review reminders.
Endpoint data shows which authentication and authorization software is actually installed and listening, which a manually kept register can miss. The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint and stores the results in the Wazuh indexer for inventory views and reports. For an identity inventory, the useful outputs are the running services, listening ports and local user and group data that reveal directories, Kerberos components, SSO agents or local accounts.
- Look for identity services: Filter the services and ports views for LDAP, Kerberos, RADIUS and web authentication components.
- Compare against the register: Reconcile each discovered identity component with a GLPI record and flag anything missing.
- Review user and group data: Use the users and groups output to spot local authentication stores that should be listed.
- Cover all endpoint types: Confirm agent coverage on servers, virtual machines and cloud hosts, since gaps there produce gaps in the list.
- Schedule reports: Export the inventory on a fixed cadence to support the annual review.
Syscollector reports what an agent can see on a host. It does not see SaaS identity providers or services that do not run on a monitored endpoint, so confirm coverage for those separately.
For self-hosted identity services, the configuration is itself the strongest record of what authenticates and authorizes users. authentik acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so each application that delegates sign-in appears as a provider object you can list and export. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, and its configuration defines the hosts, services and realms it serves. Reviewing these objects gives an authoritative list of what the identity layer really serves.
- Export provider lists: Use the administrative interface or API to list every authentication provider and the applications bound to it.
- Document the bindings: Record which applications, outposts or hosts depend on each provider.
- Inventory FreeIPA services: List the Kerberos service principals and hosts enrolled in the realm.
- Catch unmanaged applications: Compare bound applications against the register to find applications that authenticate outside the central service.
- Store configuration exports: Keep dated exports under change control so the inventory can be traced over time.
Confirm in your version of each product which export formats and API endpoints are available, and whether applications that authenticate directly against a database or local store appear in these lists at all.
The Safeguard is judged on whether the list is complete and current, and the assessment specification compares authorized and inventoried systems. A reconciliation step turns the three sources into evidence. Each quarter or at the annual review, the team compares the register, the endpoint findings and the identity configuration exports, then records the differences and their resolution. That record shows an assessor both the list and the process that keeps it accurate.
- Define one owner: Name who reconciles the sources and who approves the final list.
- Log each difference: Record unmatched systems, the decision made and the date it was closed.
- Keep dated snapshots: Retain each version of the list so the update history can be shown.
- Tie to prerequisites: Use the asset inventory and software inventory outputs, since the specification treats them as inputs to this Safeguard.
- Plan for exceptions: Document any system deliberately left off the list and the reason.
All three tools need to be confirmed in your own environment before you rely on them as evidence, including data retention, export options and access controls on the inventory itself.
Evidence that passes a 6.6 review
An assessor testing Safeguard 6.6 looks for one current inventory of authentication and authorization systems, and for proof that the inventory is kept up to date and agrees with the rest of the enterprise records. The artifacts below connect to each other, so a gap in one usually shows up in another.
Dated inventory export
The inventory itself, exported with a date and a version, listing every system that authenticates or authorizes users. Include self-hosted systems and those run by remote service providers, since the Safeguard covers both. The Assessment Specification scores the Safeguard as failing when no inventory exists or when it was last updated more than 12 months ago, so the export date is the first thing a reviewer checks. Keep prior exports so the history can be shown.
Owner and protocol fields
Each entry should name an accountable owner, the authentication or authorization protocol in use (for example OpenID Connect, SAML, LDAP, RADIUS or Kerberos), and whether the system is hosted on site or by a provider. Owner fields show who answers for a system when access must be revoked or reviewed. Protocol fields let an assessor compare the list against identity provider configurations. Blank owner fields are a common reason an inventory fails accuracy checks.
Annual review record with sign-off
A dated record showing that the inventory was reviewed at least once a year, who reviewed it, what changed, and who approved the result. The review should be a documented event, not an informal check. Schedule the next review date in advance and keep the signed record next to the export it approved. An assessor will ask for the most recent review and the one before it.
Reconciliation against software and asset inventories
A report comparing the authentication and authorization systems against the software inventory (Safeguard 2.1) and the enterprise asset inventory (Safeguard 1.1). Those two inventories are listed as prerequisites for measuring 6.6. Unlisted identity systems, or identity services found in the asset data but absent from the inventory, are the findings this report surfaces. Run the reconciliation before each review and record the exceptions and how they were resolved.
Change records for additions and retirements
Tickets or change entries showing when an authentication or authorization system was added, changed in scope, or retired, and when the inventory was updated to match. Retired systems should stay in the record with a retirement date, so the history shows what was in use. Assessors use these records to test whether the inventory follows reality between reviews rather than only at review time.
Keeping evidence current between audits
Evidence ages quickly, so assign the inventory to a named owner with a monthly or quarterly check against the asset and software data. Automated discovery exports, such as the Wazuh Syscollector data or GLPI asset records, can refresh the inputs, but a person must still confirm which entries are identity systems. Store every export, review and change entry in one controlled location with a retention rule set by your records policy.
What meeting Safeguard 6.6 costs in money and effort
This table breaks down the cost components of keeping an inventory of authentication and authorization systems, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for scoping and for asking vendors and partners what their quote includes. No dollar figures are shown because none are supplied for this Safeguard; use the drivers to build your own estimate.
| Cost component | Who carries the cost | One-time or recurring | What drives it |
|---|---|---|---|
| Discovery of identity systems | Internal IT and security staff, sometimes an implementation partner | One-time, then repeated at each annual review | Number of directories, SSO services and identity providers, plus how many are undocumented |
| Finding shadow SaaS and unmanaged applications | Security engineers, finance or procurement for expense and contract records | One-time, then recurring as new tools are adopted | Decentralized purchasing, number of business units and how much SaaS is paid for by card |
| Inventory tool (licence or self-hosted effort) | Software vendor for commercial licences; internal or partner staff for self-hosted deployment | Licence fees recur; self-hosted setup is one-time with ongoing upkeep | Commercial per-asset or per-user licensing versus open-source deployment, hosting and maintenance hours |
| Integration and data entry | Platform or IT engineers who connect directories, SSO and asset sources | One-time per integration, then recurring for changes | Count of integrations and whether records can be fed automatically rather than entered by hand |
| Vendor-hosted system owner time | Application owners and vendor management staff at each service provider | Recurring at each review | Number of externally hosted systems and whether the provider supplies a current list of its authentication components |
| Annual review and update | System owners, security governance staff and the inventory maintainer | Recurring, at least once a year | Frequency of change, team size and whether the inventory is kept current between reviews |
| Assessor sampling and evidence | Internal compliance team; independent assessor for any formal assessment | Recurring at each assessment cycle | Assessor sampling depth, number of systems selected for testing and how quickly evidence can be produced |
Which parts of 6.6 are worth outsourcing
The part of Safeguard 6.6 where outside help usually saves the most time is finding the systems that nobody listed. Identity sprawl tends to hide in places an internal team does not routinely look: a departmental SaaS tool that accepts company logins, a self-hosted LDAP directory left over from an old project, a RADIUS server behind a network appliance, or an OAuth client registered by a developer for a pilot. Someone with identity platform experience can run structured discovery across the cloud tenant, the single sign-on logs, the DNS and certificate records and the firewall rules, then reconcile what turns up against the list the organization already keeps. That reconciliation is tedious work, and it is also where most of the gaps in the inventory are found.
Ownership decisions should stay in-house. Someone accountable at the organization must decide which discovered systems are authoritative, which are retired, which are sanctioned exceptions, and who owns each record. The assessor will test whether those decisions were made and recorded, and an implementation partner cannot make them on the organization's behalf. Sign-off on the inventory, including the annual review that the Safeguard requires, also belongs to the organization. A reasonable division of labor is that the partner prepares the discovery output, the draft inventory with fields for owner, purpose, authentication method and hosting location, and the reconciliation notes, while internal staff approve every entry.
Be clear about what the outside party produces. DeployOpen prepares systems and evidence for an assessment, including the inventory, the discovery method and the review records. Only an independent assessor or auditor issues results on whether Safeguard 6.6 is met. When you scope the work, ask the provider to state in writing which artifacts it will hand over, who keeps the source data, and how the inventory will be kept current after the engagement ends. An engagement that ends with a one-time spreadsheet and no review cycle will fail the twelve-month test that the assessment specification applies.
Common questions about the Safeguard 6.6 inventory
Do IG1 organizations have to keep an inventory of authentication and authorization systems?
No. Safeguard 6.6 is assigned to Implementation Groups 2 and 3, so an organization that fits only IG1 is not expected to meet it to be aligned with that group. IG1 is the essential cyber hygiene baseline, and the work it expects covers asset and account basics. Organizations that already keep a list of their identity providers and sign-in systems will find 6.6 mostly a matter of formalizing it. Confirm your Implementation Group against the CIS Controls Implementation Groups page before scoping, because a contract or framework you also answer to may ask for 6.6 regardless of group.
How often must the authentication and authorization systems inventory be reviewed?
The Safeguard asks for a review and update at least once a year. The CIS Controls Assessment Specification fails the Safeguard when no inventory exists or when it was last updated more than 12 months ago, so an annual cycle with a dated record of each review is the practical minimum. Most teams also update the list when they add, retire or change a sign-in system, because a stale list fails the assessment even if nothing else has changed. Ask an assessor which date and version of the list they will accept as evidence.
Do vendor-hosted sign-in systems count toward Safeguard 6.6?
Yes. The Safeguard covers systems that authenticate and authorize users whether they run on your own infrastructure or are operated by a remote service provider. Software-as-a-service identity providers, hosted single sign-on services and external directories all belong on the list. Record the provider, what it authenticates, which applications depend on it and who administers it. Vendor-hosted systems are often the entries teams miss, so compare the list against your application inventory and your identity provider's connected application list.
How does Safeguard 6.6 relate to Safeguards 5.5 and 13.5?
Safeguard 6.6 is a prerequisite for both. Safeguard 5.5 covers the inventory of service and system accounts, and 13.5 covers managing access control for remote assets. The CIS Controls Assessment Specification lists 6.6 as an input to each, so an inaccurate authentication inventory weakens those measurements too. Treat the list as the shared source of truth: the systems named in 6.6 should be the same systems whose accounts you list under 5.5 and whose remote access rules you document under 13.5. Confirm the exact dependencies in the Assessment Specification for the version you are measuring against.
How much effort does a first authentication inventory take, and what does it need from the client team?
The effort depends mostly on how many identity systems exist and how well they are documented. Organizations with one central directory and a few federated applications can finish quickly, while those with legacy directories, shadow sign-in tools or many vendor-hosted applications need longer discovery. The work needs an identity engineer who can export connected applications from each system, a application owner who confirms which systems their team relies on, and a procurement or vendor management contact who can identify hosted providers. Ask any partner for a written scope that lists the systems in view, the people who must confirm them and the review cadence after handover.
Can we build the Safeguard 6.6 inventory ourselves?
Yes, many organizations do. The Safeguard asks for a list, not a specific product, so an internal team can build it in a spreadsheet, a configuration management database or an asset tool. The harder part is accuracy: the list must match what the Assessment Specification compares against your authorized and inventoried systems. Open-source options include GLPI, whose Assets module can record software and related inventory, and authentik and FreeIPA, which can show which applications delegate sign-in to them. Whoever maintains the list should own it, review it annually and keep dated evidence. If your team lacks the time or the identity engineering skills, DeployOpen can prepare the systems and evidence under a fixed-scope agreement, while the organization keeps ownership of the control.
Where organizations fall short on 6.6 and how to close it
Most organizations that fail Safeguard 6.6 do not lack an inventory. They lack an inventory with an accountable owner, a recent review date, vendor-hosted systems and a link back to the software inventory. The cards below cover the gaps assessors look for first, with a closing action for each.
Inventory with no named owner
A list of authentication systems that nobody maintains goes stale within a few changes. Each entry should name an accountable owner who can confirm the system still exists, what it authenticates and who approves changes to its access settings. Check that every row has a person, not a team alias with no one behind it, and that the owner has agreed to the role in writing. Closing action: assign one owner per system and record the owner's name and role in the inventory.
Undated reviews that fail the test
The Safeguard 6.6 assessment specification scores the control as failing when the inventory was last updated more than 12 months ago. An inventory with no revision date, or a date that only reflects a file copy, gives an assessor nothing to verify. Keep a revision history with the date of each review and the name of the reviewer. Closing action: record a review date on every entry, set a recurring review in your change calendar, and retain the prior version so the trail is visible.
Vendor-hosted identity tools missing
Safeguard 6.6 covers systems run by remote service providers as well as self-hosted ones. SaaS single sign-on, hosted identity providers, customer identity services and vendor administration consoles are often adopted by a business unit and never added to the central list. Check procurement records, expense reports and identity provider application catalogs for sign-in integrations that have no inventory entry. Closing action: add each hosted service with its provider, contract owner and the data location of its user directory.
Inventory not reconciled to software
The assessment specification treats the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) as prerequisites for measuring 6.6. An authentication system that runs on a server or application missing from the software inventory is effectively invisible to the measurement. Compare the authentication list against the software and asset inventories and flag any identity component found in one but not the others. Closing action: run a monthly or quarterly reconciliation and record the unmatched items with a resolution date.
Authorized and inventoried systems diverge
The accuracy measure in the assessment specification compares the systems that are authorized to authenticate users with those recorded in the inventory. Gaps appear when a directory is connected to a new application, a test tenant stays active after a project closes, or a legacy LDAP bind is kept for a single job. Each divergence is a finding even when the access itself is legitimate. Closing action: compare the list of authorized connections in each identity provider with the inventory and close every mismatch before the review date.
How DeployOpen prepares the 6.6 inventory and evidence
DeployOpen's role in Safeguard 6.6 is preparation, not attestation. Under a fixed-scope engagement agreed in writing before work starts, we deploy and configure self-hosted tooling inside the client's own cloud accounts, data centers or air-gapped networks, then document how the inventory is kept current and how it is reviewed. The organization owns the control: it decides which systems count as authentication and authorization systems, who maintains the list, and what the annual review looks like. An independent auditor or assessor is the only party that tests the result and issues any report or certificate.
In practice, the inventory has to cover identity providers and access systems that run on site and those operated by remote service providers. Where the client uses authentik as an identity provider for applications, we can document each application provider it serves through OAuth2, OpenID Connect, SAML, LDAP, RADIUS or proxy providers, and record where FreeIPA handles single sign-on for Linux and UNIX hosts. Each entry should carry an owner, a system type, a hosting location and a last-reviewed date. Confirm with your own team which SaaS identity services sit outside your estate, because those are the entries most often missing from a first list.
The evidence an assessor will ask for is the dated inventory itself, the record of the most recent review, and proof that the list matches reality. The CIS assessment specification fails the Safeguard when no inventory exists or when it was last updated more than 12 months ago, and it compares authorized systems against those inventoried. We can wire inventory data from GLPI Assets and the Wazuh Syscollector module into a reconciliation step, so that discrepancies surface before the assessor finds them. Ask the auditor which evidence format and sampling they expect before the engagement starts, because the inventory format is often the one thing that is hard to change late.
