Safeguard 6.6: Establish and Maintain an Inventory of Authentication and Authorization Systems

To meet the safeguard 6.6: establish and maintain an inventory of authentication and authorization systems requirement, you must maintain a current, reviewable list of every system that authenticates users or authorizes access (human and machine), show who owns each system, and prove the inventory is kept up to date and used in access-related change and risk workflows. ¹

Key takeaways:

• Inventory all authentication and authorization systems, including cloud IdPs, PAM, SSO, MFA, directory services, and application-level authorization engines. ¹
• Make the inventory operational by tying it to change management, onboarding/offboarding, and periodic access reviews, not a one-time spreadsheet. ²
• Retain evidence of ownership, refresh cadence, and updates triggered by new apps, mergers, and third-party integrations. ¹

Authentication and authorization break in predictable ways: an acquired business keeps an old directory service alive, a new SaaS app rolls its own roles, an API gateway issues tokens outside your main IdP, or a third party integration gets “temporary” credentials that never expire. Safeguard 6.6 exists to stop that drift by forcing you to name, own, and continuously track the systems that decide “who are you?” and “what are you allowed to do?”. ¹

For a CCO or GRC lead, the fastest path to operationalizing this requirement is to treat it as a governed inventory with workflow hooks. Your goal is audit-ready clarity: (1) a complete list of authentication and authorization systems, (2) an accountable owner per system, (3) defined update triggers, and (4) repeatable evidence that the inventory is maintained over time. ²

This page gives requirement-level implementation guidance you can hand to IAM, Security Engineering, IT Ops, and Application Owners. It also covers the exam questions you will get, the artifacts you must retain, and a practical execution plan that works even if your environment has multiple IdPs, hybrid AD/Azure AD, and heavy SaaS adoption. ¹

Requirement: Safeguard 6.6 inventory for authentication and authorization systems

Objective: Maintain an inventory of the systems that perform authentication (identity verification) and authorization (access decisioning), and keep it current as your environment changes. ¹

This requirement is assessment-friendly because it is measurable: either you can produce the inventory, show it’s current, and show you use it, or you cannot. ¹

Regulatory text

Provided excerpt: “CIS Controls v8 safeguard 6.6 implementation expectation (Establish and Maintain an Inventory of Authentication and Authorization Systems).” ¹

Operator interpretation:
You must (a) identify every service that issues, validates, or brokers identity and access decisions, (b) record enough attributes to manage risk and change, and (c) maintain the record as a living control with recurring evidence capture. ¹

Plain-English interpretation (what “counts”)

Authentication systems commonly include:

• Enterprise IdP/SSO (cloud and on-prem)
• Directories (AD/LDAP), federation services
• MFA services
• PKI, certificate authorities, device identity platforms
• API identity/token services (OAuth/OIDC issuers, token brokers)
  Authorization systems commonly include:
• RBAC/ABAC engines, policy-as-code (where used)
• PAM authorization workflows (who can elevate, when)
• Application-level role/permission stores
• Cloud IAM permission models (cloud provider IAM, SaaS admin consoles)
• Network access control authorization points (VPN, ZTNA gateways)

A fast test: if a system can grant, deny, or elevate access, or can mint/validate credentials or tokens, it belongs in scope. ²

Who it applies to

Entity scope: Enterprises and technology organizations adopting CIS Controls v8. ¹
Operational scope: Any environment where access is mediated by multiple tools, clouds, SaaS platforms, third parties, service accounts, and APIs. This is especially relevant if you have:

• Hybrid identity (on-prem directory plus cloud IdP)
• Multiple business units with separate SaaS stacks
• Third party integrations that rely on SAML/OIDC, API keys, or service accounts
• DevOps teams deploying apps with embedded authorization logic

What you actually need to do (step-by-step)

Step 1: Define your inventory boundary and taxonomy

Document what you will include:

• System types: IdP, directory, MFA, PAM, authorization engine, token service, app-local authz store, cloud IAM, etc.
• Identity types: workforce users, privileged users, contractors, customers, service accounts, workload identities
• Decision points: where authN happens, where authZ happens, where sessions/tokens are issued and revoked

Write this as a one-page “Inventory Standard” owned by Security/IAM with GRC oversight. ¹

Step 2: Discover systems (don’t rely on tribal knowledge)

Use multiple discovery paths:

• IAM team: list enterprise IdP/SSO, MFA, federation, provisioning tools
• IT Ops: AD domains/forests, VPN/ZTNA, endpoint auth components
• Cloud team: cloud IAMs, identity federation, workload identity components
• AppSec/Engineering: applications with custom auth/roles, policy engines, API gateways and token issuers
• Third party management: major third party integrations that include delegated auth or shared admin access

Output: a draft inventory with “known unknowns” called out explicitly (for example: “Line-of-business apps with local roles not yet validated”). ²

Step 3: Normalize required fields (make it auditable and useful)

Minimum recommended fields per system:

• System name and environment (prod/non-prod if distinct)
• System category (authentication, authorization, or both)
• Owner (role + named accountable individual)
• Business purpose and supported user populations
• Authoritative identity source (where identities originate)
• Integration points (SSO connections, directories, APIs, SCIM provisioning)
• Privileged access path (admin consoles, break-glass, emergency access)
• Logging location (SIEM feed, audit log retention owner)
• Change control hook (ticketing queue / CAB / engineering repo)
• Third party involvement (hosted SaaS, managed service, shared responsibility notes)
• Last reviewed date and review evidence pointer

If you can’t populate every field on day one, require owner + system type + business purpose + logging location first, then backfill. ¹

Step 4: Assign ownership and RACI that survives org changes

You need one accountable owner per system. Avoid “team owns it” without a named role.
A workable RACI pattern:

• Accountable: IAM lead for enterprise IAM platforms; application owner for app-local authZ; cloud platform owner for cloud IAM
• Responsible: system admins/engineers
• Consulted: Security (SecOps/AppSec), Privacy (where customer identity is in scope), GRC
• Informed: IT Service Management, Internal Audit

Record the owner in the inventory itself. ²

Step 5: Operationalize updates (the difference between a spreadsheet and a control)

Define update triggers and wire them into existing workflows:

• New application onboarding requires declaring authN/authZ method and inventory entry
• New SaaS procurement requires identifying SSO/MFA and admin authorization model
• M&A integration requires listing legacy directories/IdPs and decommission plans
• Third party integration reviews require recording token/credential issuance points
• Material IAM changes (new MFA provider, new PAM, new federation) require inventory update

Make “inventory updated” a required field or checklist item in your change management and security review templates. ¹

Step 6: Set a review cadence and capture recurring evidence

Pick an operational cadence you can sustain and document it (for example: periodic review by IAM and GRC, plus event-driven updates on changes). Keep it simple:

• Periodic attestation by system owners that entries are accurate
• Spot-check sampling by GRC/Internal Audit against reality (SSO app catalog, cloud accounts, PAM vaults)

Daydream can help by turning this into a recurring evidence workflow: owners attest, evidence is timestamped, and exceptions are tracked to closure instead of living in inboxes. ¹

Required evidence and artifacts to retain

Keep artifacts in a system that preserves timestamps and change history.

Core artifacts

• Inventory export (CSV/PDF) with required fields and owner mapping
• Inventory standard / procedure describing scope, fields, triggers, and cadence
• Evidence of periodic review (attestations, meeting notes, ticket approvals)
• Change records showing inventory updates tied to onboarding/procurement/changes
• Exceptions register for systems not yet inventoried or missing fields, with remediation owners

Nice-to-have artifacts (high audit value)

• Screenshots or exports from IdP app catalog and PAM system list mapped to inventory entries
• Architecture diagrams showing authN/authZ flows for critical apps
• List of third party connections using federation or API tokens, linked to inventory items

Common exam/audit questions and hangups

Expect these questions:

1. “Show me the inventory.” Provide the export and explain scope boundaries.
2. “How do you know it’s complete?” Explain discovery sources and reconciliation against IdP catalogs, cloud IAM accounts, and procurement/onboarding.
3. “Who owns each system?” Point to named owners and escalation paths.
4. “How is it maintained?” Show the procedure and two examples of updates tied to change tickets.
5. “What about application-level authorization?” Auditors often find gaps here; show how you identify apps with local roles/permissions.

Hangups:

• Teams inventory the IdP but miss app-local RBAC tables and SaaS admin authorization models.
• Inventory exists, but no evidence of periodic review or updates after changes. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating the inventory as a one-time project	It becomes stale after new SaaS and app releases	Add update triggers to procurement, onboarding, and change workflows 1
Listing only “IAM tools”	Authorization lives inside apps, cloud platforms, and SaaS consoles	Require app owners to declare authZ model and where roles are managed
No named owners	Accountability collapses during reorganizations	Record accountable owner and backup role in the inventory
Ignoring machine identities	Service accounts and workload identities often have broad access	Include token issuers, secrets managers, CI/CD identity, and API key systems
No evidence trail	You can’t prove maintenance	Keep attestations, tickets, and exports with timestamps 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard. Practically, failures here amplify incident impact: if you can’t quickly enumerate where authentication and authorization decisions occur, you will struggle to contain account takeover, revoke tokens, rotate credentials, or identify which systems require emergency access changes. ¹

Practical 30/60/90-day execution plan

First 30 days: Stand up a defensible baseline

• Publish the inventory standard: scope, definitions, required fields, and update triggers. ¹
• Produce a first-pass inventory from IAM/IT/cloud sources and mark unknowns.
• Assign owners for the top systems (IdP, directory, MFA, PAM, core SaaS admin planes).
• Decide where the inventory lives and how changes are approved (ticketing + evidence capture).

Days 31–60: Close completeness gaps and bind to workflows

• Reconcile inventory against IdP SSO app catalog and procurement/SaaS list.
• Add application-level authorization entries for critical apps (customer portals, finance, HR, code repos).
• Update onboarding/procurement/security review templates to require inventory updates. ²
• Start owner attestations for assigned systems and track exceptions.

Days 61–90: Make it continuous and audit-ready

• Run the first periodic review cycle and retain evidence.
• Implement sampling checks (GRC/Internal Audit) against system-of-record sources.
• Define KPIs qualitatively (for example: “all critical auth/authZ systems have named owners and logging locations recorded”) and report exceptions to security governance.
• If using Daydream, automate reminders, collect attestations, and store immutable evidence snapshots aligned to Safeguard 6.6. ¹

Frequently Asked Questions

Does Safeguard 6.6 require one centralized IAM platform?

No. It requires an inventory of the systems you have and proof you maintain it. Centralization can reduce complexity, but the control can be met in heterogeneous environments. ¹

Do application-level roles and permissions count as “authorization systems”?

Yes if the application is making access decisions based on its own roles, groups, or policies. Put the app (or its policy engine) in the inventory with an owner and a pointer to where roles are administered. ²

How do we handle third party SaaS where authorization is in the vendor’s admin console?

Inventory the SaaS admin plane as an authorization system, record who administers it, and record how admin access is controlled (SSO, MFA, break-glass). Treat it as a third party dependency with shared responsibility notes. ¹

What’s the minimum evidence an auditor will accept?

A current inventory export, a written procedure describing maintenance, and examples of updates tied to real changes or reviews. Without timestamps and ownership, the inventory reads like a static document. ¹

How do we scope customer identity (CIAM) for this safeguard?

If you operate CIAM or customer SSO, include those systems because they authenticate users and authorize access to customer-facing applications. Separate workforce IAM and CIAM in the inventory to keep ownership and logging clear. ¹

We have multiple AD domains and cloud tenants. Do we need separate entries?

Yes if they represent distinct authentication/authorization control planes with different admins, policies, or logging. Create separate inventory items and link them as related systems. ²

Footnotes

1. CIS Controls v8

2. CIS Controls Navigator v8