CC6.1 Logical access security: requirements and evidence

What CC6.1 logical access security asks for in a SOC 2

CC6.1 asks the organization to protect its information assets from unauthorized access by using logical access security software, infrastructure and architecture. In a SOC 2, that means you must show that the systems holding customer data are reached only by people and services that have been identified, authenticated and given the access they need, and that the paths into those systems are controlled. The criterion is the first in the CC6 series, which covers logical and physical access. When a customer asks for SOC 2 evidence, CC6.1 is usually the first question because it describes the whole access model, not one tool. The underlying risk is unauthorized access through identity, authentication and access paths: a stolen password, an account nobody remembers, a shared admin login, an old contractor key or an internal application reachable without sign-in. This is hard in practice because identities are scattered across cloud consoles, source control, databases, VPNs and legacy applications, each with its own user store and its own idea of MFA. Shared accounts and service credentials are often undocumented. Legacy apps may not support modern single sign-on at all, so the auditor will look for compensating controls. CC6.1 sits alongside three neighbors. CC6.2 covers registering and authorizing users before access is granted and removing it when they leave. CC6.3 covers changing and reviewing roles over time, including least privilege and segregation of duties. CC6.6 covers threats arriving from outside the system boundary, such as remote and external access. The 2017 Trust Services Criteria points of focus under CC6.1 are guidance for designing and evaluating controls, not separate requirements, so you do not need to address every one. Start by listing every identity store and access path, then confirm with your auditor which ones they expect to see in scope.

Which systems, identities and access paths fall in CC6.1 scope

CC6.1 applies to whatever the system description places inside the boundary, so scope starts with that boundary and then works outward to every place an identity can reach production data. The cards below cover the components that most often surprise teams, and the decisions that determine how much of the work is theirs and how much a provider's SOC report can carry.

Production and supporting infrastructure

Production hosts, databases, object storage, container clusters and the networks between them sit inside scope when they store, process or transmit customer data. Supporting infrastructure, such as CI runners, bastion hosts, log pipelines and backup systems, is often overlooked, yet an attacker who controls it can reach the protected environment. Map each component to the system description, then confirm which logical access controls apply to each one.

Administrative consoles

Cloud consoles, hypervisor management, Kubernetes dashboards, database admin tools and vendor portals grant the broadest privileges in the environment. Auditors usually expect these to sit behind the strongest authentication and the narrowest role grants, and they will ask who can reach each one. Treat every administrative console as in scope, even when it runs outside the production network.

SaaS tools that hold customer data

Support desks, CRM systems, analytics platforms, email, source control and file shares can all contain customer data or credentials. Whether they fall in scope depends on what they hold and whether they are part of the system described to users. Inventory them with the data they receive, then record which identity provider signs users in and which accounts hold administrator rights.

Internal applications and identity sources

Internal tools, admin panels and single sign-on configurations decide who reaches production functions. Each application needs a defined login path, and the directory behind it, whether LDAP, Active Directory or an identity provider, becomes a scoped system because changes to it alter access everywhere. Confirm that every internal application either delegates sign-in to the central provider or has a documented reason it does not.

Service accounts and API keys

Non-human identities such as service accounts, deployment tokens, API keys and CI secrets often carry standing privileges and rarely have an owner who reviews them. They are in scope wherever they can read or change protected data. List each one, its owner, the systems it reaches and how its secret is stored and rotated, since auditors commonly ask for this list early.

Third-party and subservice access

Vendor support staff, contractors, managed service providers and cloud hosts may reach systems or data directly. Access granted to these parties is part of the logical access picture, and the organization must control it. Where a cloud provider runs part of the infrastructure, the provider's own controls may cover some criteria, but the organization still needs to show how it oversees that reliance and which controls remain its own.

How identity, authentication and access paths fit together

An assessor testing CC6.1 wants to see one chain of trust rather than a set of separate logins. The chain starts with a central identity source where every human and service identity is created, grouped and disabled. Applications, consoles and infrastructure then delegate sign-in to an identity provider instead of keeping their own user databases. In open-source stacks this is commonly authentik, which acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. FreeIPA fills a similar role for Linux and UNIX hosts, providing single sign-on through an MIT Kerberos KDC. Keycloak and Zitadel are other identity providers that organizations evaluate for the same job. Confirm which protocols and directory integrations your chosen product supports for each application before you design around it.

Multi-factor authentication belongs at the identity provider, not in each application, so that one policy governs every path. Keycloak supports passkeys, recovery codes and TOTP or HOTP one-time passwords, and Zitadel's login policies can force every user, or only locally authenticated users, to register a second factor. Decide which population must enroll, how recovery works without weakening the factor, and who approves exceptions. Encryption is the second half of the picture: sensitive data should be encrypted at rest in databases, object storage and backups, and in transit between users, services and the identity provider. Record where keys are held and who can use them, because an assessor will ask.

The diagram that follows traces the access paths that must route through this identity layer: web consoles, SSH sessions, database connections and API calls. For each path, ask whether a named identity authenticates it, whether MFA applies, and whether the session can be logged and revoked centrally. A direct database login with a shared password, or an SSH key copied onto a jump host with no owner, breaks the chain regardless of how strong the identity provider is. Walk each path once with your control matrix open and note the exceptions you find, since those exceptions are what the auditor will sample.

How an assessor tests CC6.1 logical access security

This table compares each area an assessor typically examines under CC6.1, the test approach, the evidence requested and the findings that come up most often. Read it as a checklist of what to have ready before fieldwork, since the same gaps tend to appear across many Type 2 examinations. The main takeaway is that assessors test both the configuration and the operating record, so a correct setting without a dated review or sample trail is often reported as an exception.

Test area	Test approach and evidence requested	Common findings
Identity provider configuration	Assessor inspects the identity provider settings for password rules, session lifetimes, lockout behavior and which applications delegate sign-in to it. Expect exported configuration, screenshots dated to the examination period and change history.	Applications with local accounts that bypass the central provider, or settings changed without a recorded approval.
Multi-factor authentication sampling	Assessor selects a sample of user and privileged accounts and checks that a second factor is registered and enforced. Evidence includes enrollment reports and policy exports showing which groups are covered.	Privileged or service-related accounts excluded from the policy with no documented reason.
Access paths to production	Assessor traces how engineers reach production consoles, databases, Kubernetes clusters and hosts, and checks that access passes through approved, authenticated paths. Evidence includes network diagrams, bastion or VPN configuration and access logs.	Direct shell or database access with shared keys that never passes through the authenticated path.
Encryption of sensitive data	Assessor inspects how sensitive data is encrypted at rest, including key management, key rotation and who can access keys. Evidence includes encryption settings, key policies and the list of stores holding sensitive data.	Backups, replicas or logs holding sensitive data that are missing from the encryption inventory.
Shared and default credentials	Assessor searches for default administrator passwords, shared accounts and long-lived static secrets in configuration. Evidence includes the account inventory, secrets manager records and the procedure for rotating credentials after staff changes.	Vendor default accounts left enabled on appliances or self-hosted services, or shared accounts used by several staff.
Privileged access and reviews	Assessor checks who holds administrative rights, whether elevation is approved and logged, and whether periodic reviews were completed and acted on. Evidence includes role membership exports and signed review records.	Access review sign-offs that do not show the reviewer compared the list with current roles.
Exceptions and reporting	Assessor records each deviation found in the sample, asks management for root cause and remediation, and decides whether it affects the opinion. Evidence includes the exception log, ticket history and the management response.	Exceptions discovered by the auditor that management had not recorded or tracked internally.

Implementing CC6.1 step by step

This sequence turns CC6.1 from a policy statement into a working logical access layer: a known set of systems and access paths, one identity source, enforced authentication, controlled privileged access, protected data and a control matrix that points auditors to the evidence. Each step ends with an artifact the assessor can sample.

Inventory systems and access paths
Start by listing every system in the SOC 2 boundary: production applications, databases, cloud consoles, Linux hosts, CI/CD, monitoring, backup consoles and internal tools. For each one, record how people and services reach it, including web logins, SSH, database clients, API keys, VPN and break-glass accounts. The engineering lead and the platform team usually build this list together, and an access inventory that names an owner for every system is the output. The step is done when someone outside the build team can walk the list and find no unexplained entry point.
Choose the central identity source
Decide which directory or identity provider will be the single source of user identities for the in-scope systems. Options include an LDAP or Kerberos directory such as FreeIPA, or an identity provider such as authentik, Keycloak or Zitadel, each of which handles sign-in differently. Confirm each candidate against your application list, because not every product supports every protocol your applications need. The output is a short decision record naming the source of truth, who administers it and which accounts are allowed to exist outside it.
Deploy the identity provider and connect applications
Install the chosen identity provider inside your own infrastructure, then register each application as a client or provider. authentik exposes OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications that cannot speak modern protocols can still delegate sign-in. Remove or disable local application passwords once the application is connected, and test that a disabled directory account can no longer sign in. The output is an SSO coverage list showing each application, its protocol, its owner and whether local login still exists.
Enforce MFA and password policy
Configure multi-factor authentication and password rules in the identity provider rather than in each application. Keycloak supports passkeys, recovery codes and configurable one-time password policies, and Zitadel offers TOTP, U2F security keys, passkeys and one-time passwords with an option to force a second factor for every user or for local accounts only. Document the chosen factors, the recovery process and the exceptions. The output is a configuration baseline export plus a test log showing a login that fails without the second factor.
Route privileged and infrastructure access through controlled identity
Move administrative access to servers, Kubernetes clusters, cloud consoles and databases behind the same identity source, so that engineers authenticate with their own accounts and not shared credentials. FreeIPA can provide single sign-on for Linux and UNIX hosts through a Kerberos KDC, and access proxies can gate privileged sessions. Keep a small, separately logged break-glass account with its credential stored under dual control. The output is a privileged access map that lists each infrastructure target, the identity path to it and the group that grants it.
Encrypt sensitive data
Identify where sensitive data is stored and transmitted, then enforce encryption in transit with TLS on every externally reachable and internal service that carries it, and encryption at rest on databases, object storage, backups and volumes. Decide who manages keys and where they live, and restrict key administration to a small group separate from application administrators. Confirm the settings with your cloud provider or storage platform, since the exact options depend on the product. The output is an encryption register that lists each data store, its encryption setting, its key owner and the check that verifies it.
Document the control matrix entries
Write the CC6.1 row of the control matrix: the control description in your own words, the owner, the system scope, the frequency, the evidence source and the test the auditor will perform. Link each row to the artifacts from the earlier steps, such as the access inventory, the SSO coverage list, the configuration baseline and the encryption register. The control owner reviews the entries, and the auditor later checks whether the described control matches what the systems do. The output is a control matrix entry that an independent auditor can trace to evidence without asking the team to explain it.

Which evidence satisfies CC6.1 and how to keep it current

CC6.1 is tested by looking at what your identity and access systems actually do, and at proof that they kept doing it across the whole observation period. The cards below cover the records an assessor typically asks for and how to collect them continuously, so the Type 2 period is not reconstructed from screenshots at the end.

Identity provider configuration exports

Export the configuration of your identity provider on a schedule and keep each snapshot with a timestamp and the name of the person who reviewed it. For CC6.1 this shows which authentication methods, password rules and session settings were in force on each date. Check that the export covers every application connection and every policy, not only the default realm or tenant, and that changes between snapshots match approved change tickets.

MFA enrollment reports

Produce a report listing every user account, whether a second factor is registered, and the factor type, such as an authenticator app, security key or passkey. Assessors compare this list against the user directory to find accounts without MFA and check whether each exception was approved. Confirm that the report is generated from the identity system itself, not typed by hand, and that service and break-glass accounts are listed with their own justification.

SSO coverage reports

List every application in your environment and mark whether sign-in goes through the central identity provider. Applications that keep local passwords are the gaps an assessor looks for first. Record the reason for each exception, the compensating control and a review date. Pair the list with a check of the application inventory from your asset records so that an application added last month does not sit outside the report.

Access path inventories

Document every route into the system: web consoles, APIs, SSH and database connections, VPN endpoints, and administrative tools. For each path, record the authentication method and who can use it. CC6.1 covers the architecture that protects information assets, so the inventory is evidence that you know where access enters. Review it when infrastructure changes and keep the dated versions so the auditor can see how the paths evolved.

Encryption configuration records

Keep records showing which data stores, backups and connections use encryption, which algorithms and key lengths are configured, and where keys are held and who can manage them. Capture these settings from the running systems on a schedule, not only at build time. Flag any store that falls outside the standard so the exception can be tracked to closure.

Privileged access logs and auth change tickets

Retain logs of administrative sign-ins, role grants and changes to authentication settings, and link each setting change to an approved ticket. The auditor samples these to confirm that changes were authorized and that privileged activity can be traced to a named person. Confirm that logs are shipped to storage the administrators cannot edit, and that you can filter them by date range for the audit period.

What meeting CC6.1 costs in money and effort

This table lists the cost components of meeting CC6.1 and who is paid for each, marking whether it is one-time or recurring. No prices are given because none were supplied, so use the drivers column to scope a written quote. Self-hosted open source removes license spend but not integration, rollout or evidence work.

Cost component	One-time or recurring	What drives it up or down	What to request in a written quote
Licenses or tooling	Recurring if commercial; none for self-hosted open source	Number of identity-bound applications, user count, and whether you buy commercial add-ons or support subscriptions	Itemized list of every license or subscription, with renewal terms, and confirmation that core identity components are open source
Engineering time for identity integration	One-time, with ongoing changes	Number of applications and protocols to connect (OAuth2, OpenID Connect, SAML, LDAP), and how many legacy systems need proxy or directory integration	Named deliverables per application, a hardening baseline, and who owns the configuration after handover
MFA and device rollout	One-time rollout, recurring for new joiners and device replacements	Number of users, mix of hardware security keys and authenticator apps, and whether MFA is enforced for every user or only local accounts	Rollout plan, help desk support during cutover, recovery and lost-device procedures, and enrollment reports the auditor can sample
Evidence upkeep	Recurring, usually through the full observation period	Degree of automation, such as exporting access logs and directory reports on a schedule, versus manual screenshots	Evidence list per CC6.1 control, collection frequency, and where evidence is stored and retained
External testing or review	Recurring, typically at least annually or after major changes	Size of the external attack surface, the number of identity endpoints, and whether testing covers authentication and session flows	Test scope in writing, methodology, retest terms, and the format of findings and remediation evidence
Auditor sampling and testing	Recurring with each examination, Type 2 costs more than Type 1	Number of in-scope systems, the observation period, sample sizes the auditor selects, and how many exceptions must be explained	Auditor engagement letter, the sampling approach, the evidence request list, and the fee basis for additional testing
Internal governance time	Recurring	Frequency of access reviews, number of administrators, and how often identity policies change	Documented owner for each access control and the review cadence written into the control matrix

Who owns CC6.1 and what a partner can prepare

Your organization owns CC6.1. The control is an obligation on the service organization, so management must decide which identity provider is the source of truth, who may be granted access to production and customer data, and which exceptions are acceptable. Those decisions are management judgments, and the auditor will ask who made them, when, and on what basis. An implementation partner can recommend options and build what management chooses, but cannot approve access on your behalf.

Access policy decisions: Management sets the rules for who needs multi-factor authentication, which applications sign in through central identity, and which accounts may stay local.
Access approvals: A named owner approves each access request for production systems, administrative consoles and customer data stores, and the approval is recorded.
Control operation: Your staff run the recurring work, such as periodic access reviews, disabling leavers, and investigating unexpected logins.
Management's description and assertion: Your leadership signs the system description and the written representations that the auditor relies on.
Evidence ownership: Your team keeps the records and can produce them on request without relying on a consultant.

Before engaging anyone, confirm that you can name a control owner for each CC6.1 activity and that someone internal will still operate the controls after the examination ends.

Questions buyers ask about CC6.1 cost, effort and audit testing

Can CC6.1 be met with open-source identity tools?

Yes, the criterion does not name products. CC6.1 asks that the organization protect information assets through logical access software, infrastructure and architecture, so open-source identity providers such as authentik, Keycloak, Zitadel or FreeIPA can supply much of that control when they are configured and operated well. The auditor tests whether sign-in is centralized, whether multi-factor authentication is enforced, whether access paths to sensitive systems are controlled, and whether those settings stay in place over the audit period. The organization still owns the control, its policies and its evidence. Confirm each platform's current capabilities against its own documentation before you design the control.

How long does CC6.1 implementation take, and what drives it?

The duration depends mostly on how many applications and access paths need to move under central identity, not on the identity product itself. Drivers include the number of systems that must delegate sign-in, whether directory data is clean, how many legacy or vendor-hosted tools lack standard protocols, how much existing access must be reviewed and removed, and how quickly the team can test changes without breaking production. Because SOC 2 Type 2 tests operation over a period, the control must also run long enough to produce evidence before the observation window starts. Ask any implementation partner for a written scope that lists each application, integration and test step before agreeing a timeline.

What does the work need from our internal team?

Your team owns the decisions that the auditor will test, so it must be involved from the start. Typical internal responsibilities include naming control owners, approving the access model and role design, providing directory and application contacts, deciding who may administer the identity platform, and reviewing access periodically. An implementation partner can build and document the configuration, prepare test evidence and train administrators, but it cannot approve access on your behalf or act as the control owner. Ask for a responsibilities table in the statement of work so that each deliverable has a named internal owner.

Will an auditor accept evidence from a self-hosted identity platform?

Auditors accept evidence from self-hosted systems when they can see that the control works and that the records are complete and unaltered. The auditor will ask for configuration exports, login policy settings, multi-factor enrollment reports, administrator access lists, change records for identity settings and samples of joiner, mover and leaver events. Self-hosted platforms need extra care because the organization must prove the logs are retained, that administrator activity is itself logged, and that backups and upgrades are controlled. Discuss the evidence list with your CPA firm before implementation so that you know which exports it will sample. The auditor issues the report, not the implementation partner.

How do we handle legacy applications without SSO?

Legacy applications without modern single sign-on still need controlled access, so the usual approach is to place them behind an identity-aware proxy, a gateway that enforces sign-in before traffic reaches the application, or to restrict them to a managed network path. Some platforms offer proxy providers for this purpose, but whether a given legacy app can be fronted depends on its architecture and session handling, so test each one. Where neither option works, document the risk, restrict who can reach the system, rotate and vault its shared credentials, and record the compensating controls. Auditors commonly probe these exceptions, so an informal workaround is more likely to produce a finding than a documented and tested one.

Should we hire a partner or implement CC6.1 in-house?

The decision depends on your team's capacity, existing identity skills and how many systems must change. In-house delivery keeps knowledge local and suits teams that already run directory services, but it requires time from engineers who are often needed elsewhere. A fixed-scope partner engagement can prepare the identity platform, integrations, hardening, backups and documentation under a written scope, and it can hand over runbooks so your team operates the system afterward. Either way, an independent CPA firm performs the examination. When comparing options, ask what the partner delivers, what remains with your staff, how knowledge transfer works and what support continues after the report.

Who is responsible for ongoing CC6.1 operation after the audit?

Ongoing operation is an internal responsibility that continues every month, not a one-time project. Someone must review administrator accounts, confirm multi-factor policies still apply, process joiners and leavers promptly, watch identity logs and apply platform upgrades in a controlled way. Recurring support can be purchased as a retainer for upgrades, monitoring and testing, but the control owner remains your organization. Plan for these recurring tasks in the budget at the outset, because a control that lapses between audit periods will show up as an exception in the next Type 2 report.

How DeployOpen prepares CC6.1 evidence

DeployOpen plans, implements and documents self-hosted open-source identity and access platforms inside your own infrastructure, so the logical access controls behind CC6.1 can be run and evidenced. We prepare systems and evidence for your assessment; your organization owns its controls, and only an independent CPA firm issues the SOC 2 report.

How we scope

Written scope names the identity platforms, applications, environments and access paths covered by CC6.1.
We agree which authentication methods, such as MFA factors and SSO flows, must be in place before work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before implementation begins.

How we build

We deploy the chosen identity provider in your cloud account, data center or air-gapped network, with encryption of sensitive data configured.
We configure MFA policies, password and session settings, and application sign-in delegation so access decisions are consistent and recorded.
We run security testing against sign-in, token and access paths, and log the findings and fixes for your control evidence.

How we hand over

You receive configuration records, a control narrative for CC6.1, and an evidence map showing where each access control is recorded.
We document the admin procedures your team needs to run logical access controls and collect screenshots, exports and logs for the auditor.
Handover covers a walkthrough with your team so the owners of each control can explain and reproduce how it works.

How we support

Ongoing support, upgrades and continuous testing of identity platforms are available as a retainer.
Retainers can cover periodic reconfiguration, patching and re-testing as applications and sign-in methods change during the observation period.
Confirm with your CPA firm which evidence formats they accept before the Type 2 period starts.

CC6.1 Logical access security