Keycloak SOC 2 logical access controls

How Keycloak supports SOC 2 CC6 logical access controls

In a SOC 2 examination, Keycloak can supply evidence for CC6.1, CC6.2, CC6.3 and CC6.6, the criteria covering the security software and architecture that protect information assets, the registration and removal of users, role-based access, and protection against threats from outside the system boundary. It does not cover the whole criteria set. The other common criteria in the CC6 series, and the criteria in CC1 to CC9 outside CC6, depend on physical controls, change management, risk processes and infrastructure that an identity provider does not run. Treat Keycloak as one control component, and map each criterion to the process, owner and record that sits around it.

Start with CC6.2, because it sets the rule for how users enter the system. The criterion requires registration and authorization before credentials are issued or access is granted, and removal of those credentials once access is no longer authorized. In Keycloak, decide whether user records are created directly in the realm or pulled from an authoritative source through LDAP or Active Directory user federation, and document which system approves a new account. Confirm how a deprovisioning request reaches Keycloak and whether disabling an account ends its active sessions in every application that relies on it. Test this in a non-production realm before you rely on it as evidence, and keep the ticket, approval and change record that show each step happened in order.

CC6.3 turns on role design. Keycloak supports realm roles, client roles, groups and composite roles, which let you give each application its own role set and assign access through groups so that individual grants stay rare. Segregation of duties applies to administration as well. Limit who holds realm administration rights and keep those rights separate from application business roles. Run a periodic role review, export role and group membership, and record who approved each change. If you use the Organizations feature for customer tenants, confirm how its domain and membership settings map to the access your SOC 2 scope describes.

CC6.6 asks for protection against threats from outside the system boundary, and Keycloak sits on that boundary for every sign-in. Keycloak's production guidance calls for TLS on all communication and a reverse proxy with path restrictions. Expose the admin console and Administration REST API on a different hostname or context path from public frontend URLs, and verify from outside your network that the restriction holds. For authentication, set the password policy in the realm, enable one-time passwords or WebAuthn passkeys for access that comes from outside the boundary, and plan recovery codes so that a lost device does not lead to ad hoc resets. Export the realm configuration on a schedule so an auditor can see the settings as they stood on the test date.

Keycloak configuration is only part of the evidence. DeployOpen prepares the configuration, runbooks and evidence packages that show how these controls operate, but an independent CPA firm issues the SOC 2 report. A Type 1 report evaluates the design of controls as of a date, and a Type 2 report adds an opinion on operating effectiveness over a period, so a Type 2 needs records from throughout that period. The TSC points of focus are design aids that help you design and evaluate controls. They are not separate requirements, and not every point of focus has to be addressed. Ask your auditor early which points of focus they expect to see addressed, and confirm the report type and examination period in writing before work starts.

Which Keycloak configuration maps to each CC6 criterion

This table links each CC6 criterion in scope to the Keycloak capability that supports it and the configuration an assessor will ask about. Read each row as a design input that your own procedures and review records must support. Keycloak supplies the mechanisms, but the evidence depends on how your team sets, reviews and records them.

Requirement	Keycloak capability	Configuration to set
CC6.1: logical access security software and architecture	Realms, admin console, TLS and reverse proxy	Separate realm for workforce applications; TLS on every hop; admin console and Admin REST API on a non-public hostname or path
CC6.2: register and authorize users before granting access	User registration, user federation (LDAP, Active Directory) and brokering	Disable self-registration for workforce users; federate from your directory of record; document the approval step before accounts are created
CC6.2: remove credentials once access ends	User federation and account status	Remove or disable access at the source directory so Keycloak reflects the change; confirm disabled users cannot sign in; review account lists on a set schedule
CC6.3: grant, change and remove access by role	Roles, groups and fine-grained authorization services	Assign roles to groups instead of individual users; map application roles to directory groups; record who approves each role
CC6.3: least privilege and segregation of duties	Realm admin roles and admin console access	Keep platform administrators separate from business-application roles; limit realm admin rights to named operators; log admin events
CC6.6: additional authentication for access from outside the boundary	OTP, WebAuthn, passkeys and recovery codes	Require OTP, WebAuthn or passkeys for externally reachable clients; set the OTP policy; issue recovery codes under a documented procedure
CC6.6: protect authentication and restrict boundary access	Authentication flows, production TLS and reverse proxy path restrictions	Bind required steps to the browser login flow; enforce TLS; expose only login and token endpoints publicly; confirm failed login records in 26.8 settings

How to show CC6.2 user registration and removal in Keycloak

CC6.2 expects the organization to register and authorize new internal and external users before it issues credentials or grants access, and to remove those credentials once access is no longer authorized. In a Keycloak deployment, the auditor will ask two things. First, can you show who approved each account? Second, can you show that the account in Keycloak was created from that approval and closed when access ended? Keycloak records the account state, but it does not make the approval decision, so the evidence chain has to run through systems outside Keycloak.

The approval step usually sits in an HR onboarding record, an access request ticket, or both. Decide for each user population which store is the system of record. For employees, this is often a directory such as LDAP or Active Directory connected through user federation. For partners or customers, it may be a realm user created by an administrator or a identity provider brokered through OIDC or SAML. Auditors will typically sample accounts from the Keycloak side and trace each one back to its approval. Write down the ticket or HR reference that corresponds to each account, and confirm your policy on where that reference is stored, such as a user attribute, so the trace takes minutes rather than days.

The points of focus for CC6.2 also cover reviewing whether credentials remain appropriate and preventing use of credentials that are no longer valid. Run a recurring review of enabled accounts, group memberships and registered credential types against the approved population. Confirm how federated accounts behave when they are disabled or deleted in the directory: check whether Keycloak picks up the change at the next synchronization, and whether an existing session or a cached login can still be used in the meantime. Test this with a dedicated test account before relying on it, and record the result as evidence.

When access ends, the removal should cover every place the user can still authenticate or hold a token. Disable the user, or delete the account if your retention policy allows. End active sessions. Remove or revoke registered OTP devices, WebAuthn keys, passkeys and recovery codes. Remove group and role memberships so that any residual token carries no privileges. Delete identity provider links for external accounts, and review offline sessions and granted client consents. For federated users, remove or disable the directory account as well, since Keycloak may not be the authoritative source. Confirm exact admin console steps against your release, then rehearse the offboarding path and keep the resulting admin event log.

Role-based access and least privilege for CC6.3

CC6.3 expects access to follow roles, responsibilities or system design, with least privilege and segregation of duties applied. The cards below cover the Keycloak objects that carry those decisions and the evidence each one produces. Your organization must define its own role model first, because Keycloak enforces whatever structure it is given.

Realm and client roles

Realm roles apply across the whole realm, while client roles belong to a single client and suit applications that define their own permissions. Each role definition can be exported and compared with your approved role catalog. For CC6.3, the evidence is the role definitions themselves, and the review step confirms that every role still maps to a documented responsibility and that unused roles are removed. Check whether composite roles grant more access than their names suggest.

Groups and role mappings

Groups collect users and attach role mappings, so access follows team membership, with individual grants kept to documented exceptions. A group membership export shows who holds access through each group, giving reviewers one list to check against current job responsibilities. Review nested groups carefully, because a child group inherits role mappings from its parent and a membership change can widen access without anyone editing an individual user.

Admin console and Administration REST API

The admin console and the Administration REST API both change realm configuration, users and roles, so access to them is itself a logical access control. Production guidance calls for exposing them on a hostname or context path separate from public frontend URLs. Restrict administrative roles to named operators, and confirm that service accounts used for automation hold only the realm-management roles their scripts need. Review these grants on the same cycle as application access.

Fine-grained authorization services

Fine-grained authorization services let an application request permissions based on resources, scopes, policies and permissions, which fits applications whose rules depend on the specific object being accessed. Use them only where realm and client roles cannot express the rule, since each policy adds logic that must be tested and reviewed. For evidence, export the resource server and policy definitions, and have a reviewer confirm that each policy traces to a documented access requirement.

Admin event records as review evidence

Admin events record changes made through the admin console and the Administration REST API, including who changed a role, group or client. Confirm that admin event logging is enabled and that retention meets your own policy, because these records show whether each privilege change matched an approved request. Test the setup by making a controlled role change in a non-production realm and confirming the event appears with the expected actor and resource.

Segregation of administrator and approver duties

People who administer Keycloak should not also approve the access they configure. Separate the operator who creates roles and group mappings from the approver who authorizes them, and record both in the change ticket. Where one team performs both functions, the periodic review should be carried out by someone outside the administration path. Your organization decides which duties each person holds and documents the approval matrix that Keycloak changes must follow.

How stronger authentication and boundary settings address CC6.6

CC6.6 asks the organization to apply logical access security measures that protect the system against threats originating outside its system boundaries. In a Keycloak deployment, this criterion is mostly about two things: making sign-in harder to abuse from untrusted networks, and making sure the administrative surfaces of Keycloak are not reachable the same way as the public login pages. The points of focus cover restricting access, protecting identification and authentication credentials, requiring additional authentication or credentials, and implementing boundary protection. Each of these maps to a configuration decision that you should make deliberately and record in your system description. On the authentication side, Keycloak documents OTP policies, W3C WebAuthn, passkeys with conditional and modal UI, and recovery codes. An OTP policy defines the algorithm, digits and period for one-time passwords, and it is applied through the realm's authentication flows and required actions. WebAuthn and passkeys give phishing-resistant options for users who can register them. Decide which user groups must complete a second factor, which methods are permitted for each group, and how a user who loses a device regains access. Recovery codes and the recovery path are policy decisions that the organization must document, because an auditor will test whether the recovery route is as strong as the primary sign-in.

On the boundary side, Keycloak's production guidance calls for TLS on all communication, a reverse proxy with path restrictions, and separation of the admin console and the Administration REST API from public frontend URLs. In practice, this means the public hostname serves only the login, token and account pages that applications need, while the admin console and Administration REST API are reachable only from a restricted hostname, context path or network segment. Confirm that the reverse proxy blocks the admin paths on the public host, that TLS covers every hop including the connection between proxy and Keycloak where your design requires it, and that you can show the routing rules as configuration evidence. The metrics endpoint needs the same care. Keycloak exposes Prometheus-format metrics at /metrics on its management interface when started with metrics enabled, so the endpoint should not be published on the public frontend. Verify this by requesting the path from outside your network and confirming it does not respond. Plan the test as a recurring control check, and keep the result as evidence alongside the proxy configuration. Pair these checks with your own review of which network paths can reach the management interface, since an auditor testing CC6.6 will ask for proof of the boundary, not only a description of it.

What Keycloak does not cover for SOC 2

Keycloak can enforce and log many CC6 access decisions, but an auditor tests the program around it. The cards below cover the policies, approvals, documentation, infrastructure and operating decisions that your organization must build and evidence, usually with input from several owners.

Control design and written policies

CC6.2 and CC6.3 expect written procedures for onboarding, offboarding and periodic access review at a stated cadence. Keycloak can produce user and role data for a review, but it does not set how often reviews happen or who signs them off. Check that each procedure names an owner, a frequency and the location of its evidence. Usually owned by the GRC or compliance lead, with HR and application owners.

Approval ticket trail

CC6.2 expects the organization to register and authorize users before it issues credentials. Keycloak can log account changes, but the authorization itself usually lives in a ticketing or HR system. Link each request, approver and grant with a shared identifier so an assessor can trace an account back to its approval. Removals need the same trail, because credential removal is part of the same criterion. Usually owned by IT service management, with the access owner.

System description under the 2018 criteria

Management prepares the system description and evaluates it against the AICPA's 2018 SOC 2 description criteria (DC 200), with 2022 implementation guidance. It must explain how Keycloak fits the system, including realms, federated user sources, MFA settings and the boundary it protects. The CPA firm performing the audit tests that description and issues a Type 1 or Type 2 report, and DeployOpen does not issue audit reports. Keep version and deployment details current through each upgrade. Usually owned by the CISO or system owner, with the compliance lead.

Network boundary and endpoint controls

CC6.6 asks for protection against threats from sources outside the system boundary, and Keycloak is only one layer of that protection. Keycloak's production guidance calls for TLS on all communication and a reverse proxy with path restrictions, and it recommends serving the admin console and Administration REST API on a different hostname or context path from public frontend URLs. Firewall rules, load balancer policy, VPN or zero-trust access and managed administrator endpoints sit outside Keycloak. Check each rule against the system description. Usually owned by network and infrastructure teams.

Log retention and monitoring

Keycloak can expose Prometheus-format metrics at /metrics when started with --metrics-enabled=true, and Keycloak 26.8 persists login failures to the database by default. Retention, alerting and review of authentication and admin events happen in a log platform or SIEM that you operate. Decide how long each event type is kept, who reviews it and how alerts are triaged. Then test that a sample admin change reaches the central store. Usually owned by the security operations team.

Upgrades and operator update approval

Keycloak plans four minor releases a year and a major release every two to three years, and upgrade notes can change behavior, such as enforced SMTP StartTLS and mandatory signature validation of backchannel logout tokens in 26.8. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Define who approves each upgrade, whether schema migration runs automatically at startup or is applied manually, and how changes are tested first. Usually owned by platform engineering, with change management approval.

Configuration sequence for SOC 2 access evidence

This sequence is illustrative: it shows the order in which Keycloak controls are configured so that CC6.2, CC6.3 and CC6.6 evidence exists for the audit period. Scope decisions, such as which applications and realms fall inside the boundary, change the order and the effort. Each step closes with an output the team can show an auditor.

Confirm the in-scope systems and boundary
List every application, Keycloak realm, client, admin console and integration that handles protected information, and mark which ones sit outside the boundary. The engineering lead and the compliance lead agree the list, and each business owner confirms the systems they answer for. Closing check: a scope document that names each realm, client and administrative path, along with the team that owns it. Anything missing from this document becomes a gap that an auditor will ask about later.
Define the role model and approval workflow
Map job functions to realm roles and client roles, and assign users through groups so that access follows group membership and individual grants stay the exception. Write down who approves a new account, who approves each role, and where each request is recorded, ideally in a ticketing system the auditor can sample. Closing check: a role matrix and approval rules signed by the control owner, with a named business owner for every role.
Configure the realm and identity sources
Create the realm and connect the directory or HR-maintained source the organization already trusts, such as LDAP or Active Directory user federation, or an external OIDC or SAML identity provider through brokering. Disable local accounts that bypass that source wherever policy allows. Closing check: create and disable a test user in the source and confirm the change reaches Keycloak without a manual copy.
Set authentication policies and MFA
Configure OTP policies, WebAuthn or passkeys and recovery codes in the authentication flows, then require a second factor for users who reach the system from outside the boundary. Decide how recovery codes are issued and who may reset a second factor, and record those decisions. Closing check: sign in from an external network with a test account, confirm the second factor prompt, and export the flow configuration as evidence.
Lock down admin and production endpoints
Serve the admin console and Administration REST API on a hostname or context path separate from public frontend URLs, enforce TLS on all communication, and restrict the reverse proxy to the paths the applications need. Limit administrative roles to a small named group. Closing check: confirm from outside the administrative network that the admin paths do not respond, and keep the proxy rules in version control with a reviewed change history.
Enable and verify event logging and retention
Turn on login and admin event logging, and enable the metrics endpoint with --metrics-enabled=true on the management interface if monitoring uses it. Forward events to the central log platform and agree the retention period with the log owner. Keycloak 26.8 persists login failures to the database by default, so confirm where that data is kept and who can read it. Closing check: generate a successful login, a failed login and an admin change, then find all three in the central log store.
Run a sample access review
Select a sample of users and roles, and have each business owner confirm that the access is still appropriate for the work. Remove stale accounts and roles, and record the reviewer, the date and the decision for each item. Closing check: every reviewed item has a documented decision, and every removal can be traced to a Keycloak admin event in the log store.
Capture the evidence set before the audit period
Export the configuration baseline, role matrix, approval records, MFA policy, endpoint rules, log samples and review records into a dated evidence folder. Ask the auditor which samples they plan to request, and confirm the audit period start date with them in writing. Closing check: each CC6 criterion has a named artifact and an owner, and the evidence has been checked against the period start before it begins.

Evidence auditors request and how to keep it

Auditors testing CC6.1 through CC6.6 in Keycloak usually ask for the same six kinds of evidence. Each one must show the state of access across the full examination period, so keep it on a schedule, tie it to an approver, and confirm the retention and export format with your auditor before collection starts.

Realm and client configuration exports

Dated exports of each realm, covering clients, identity providers, authentication flows and required actions, show the configuration in force on each date. Run the export on a fixed schedule and after every approved change, then store the files in write-once or version-controlled storage with the timestamp and Keycloak version recorded. The identity administrator prepares each export, and a second person signs the change log that links it to an approved ticket. Ask the auditor which export format and retention period they will accept.

Role and group membership reports

Reports listing each user's realm roles, client roles and group memberships show who held which access at each point in the period. These support CC6.3, where access must follow roles and least privilege. Record the run date, realm name and query used with every report, and keep the reports from the whole period rather than only the most recent one. The owner of each application role signs off on the membership list. Confirm the reporting cadence the auditor will sample against.

User lifecycle tickets matched to account dates

Each account creation and disablement should trace to a request ticket approved before access was granted, which is the CC6.2 requirement to register and authorize users and remove credentials when access ends. Store the ticket ID on the user record or in your identity governance system, then compare ticket dates with the Keycloak creation and disablement timestamps. Include leavers and contractors in the sample so removals are tested as closely as grants. The approver should be a different person from the administrator who made the change.

Authentication policy settings

Exports of password policy, OTP and WebAuthn or passkey settings, brute-force detection, session and token lifespans, and any conditional authentication for access from outside your network boundary show how CC6.1 and CC6.6 controls were configured. Keep each export with the change record for that policy and check that the production realm matches the approved settings. Record the Keycloak version alongside the settings, because upgrades can change defaults. The security owner signs the policy baseline at each review.

Admin and login event records

Admin events record changes made through the admin console and Administration REST API, and login events record authentication attempts and failures. Enable both in each realm, then export them on a schedule to your log platform so the record survives database cleanup. Keycloak 26.8 persists login failures to the database by default, so confirm how that data is pruned and how long it is kept. Restrict who can read these logs and log access to them. The security operations lead reviews a sample each period.

Access review records

Periodic access reviews show that an accountable owner confirmed or removed each user and role in scope, which supports the review points of focus under CC6.2 and CC6.3. Use a dated export of the membership under review, record each decision and its reviewer, and file the revocation tickets that follow. The application or data owner signs the completed review. Confirm with the auditor how many review cycles they expect across the period and whether they need the reviewer's rationale for each decision.

Questions buyers ask before hiring outside help for SOC 2 with Keycloak

What drives the cost of SOC 2 access control work on Keycloak?

Scope size and the number of applications drive most of the cost, because each application that signs in through Keycloak needs its access paths mapped, tested and evidenced. Federation sources come next. Each LDAP or Active Directory connection, and each external identity provider brokered through Keycloak, adds mapping and reconciliation work. The existing role model is another driver. Documented roles that match job functions take less time to rework than groups and client roles built up over years without an owner. Evidence gaps, such as missing access request tickets or no record of past reviews, add collection and remediation effort.

Cost components: one-time design and build work, plus recurring items such as periodic access reviews and evidence collection. Ask for a quote that lists these items separately, names the applications in scope, and states which evidence you are assuming already exists.

Can our own team set up Keycloak for SOC 2 without a partner?

Yes, if your team has Keycloak administration skills, working knowledge of the CC6 criteria and the time to run the project alongside normal operations. Confirm four things first. Someone must own control design and the evidence calendar. Someone must understand what the auditor will test, including how registration and removal of users under CC6.2 and role-based access under CC6.3 will be shown. Your team needs a tested path for Keycloak upgrades, because the release cadence will keep changing the environment. Finally, confirm that configuration can be exported and reviewed, so every change leaves a trail.

If any of these is missing, a fixed-scope engagement can cover the gap while your team keeps ownership of the controls.

How long does a Keycloak SOC 2 access control project take?

Timing depends on scope and readiness, and no single duration applies to every environment. The main drivers are the number of applications to map, the number and type of federation sources, how much of the joiner, mover and leaver process is automated through HR and ticketing systems, and how many evidence gaps exist at the start.

The audit window also sets timing. Type 1 preparation can be planned around one date, while Type 2 preparation must cover a period during which the controls actually operated, so the calendar limits how early the work can finish. Ask for a schedule in the written scope that shows dependencies on your approvals, system access and change windows, and marks which milestones depend on the auditor.

What does our organization need to provide for this engagement?

Most of the work depends on access and decisions from your people, so confirm the inputs before work starts. System owners must identify which applications sign in through Keycloak, who administers each one and which roles they should carry. The project needs read access to HR records that define joiners, movers and leavers, and to the ticketing system that holds access requests and approvals.

A named approver must sign off role designs and exceptions, and that person needs authority to decide. Your team should also share its audit calendar, including the auditor's fieldwork dates and the period the report will cover. Ask the partner to list each input, its owner and its due point in the written scope, so delays appear early.

What is the difference between SOC 2 Type 1 and Type 2 preparation for access controls?

Type 1 preparation focuses on whether controls are designed and in place as of a specific date. Type 2 preparation also has to show that the controls operated consistently across an observation period. For Keycloak access controls, the difference is practical.

Type 1 work centers on design: how users are registered and authorized, how roles map to job functions, how multi-factor authentication applies to access from outside the system boundary, and how access is removed. Type 2 work adds proof over time, including records of approvals, periodic reviews of roles and accounts, timely removal of leavers and logs showing the controls ran. Ask any partner which type the quote covers and how evidence will be collected across the period.

Can DeployOpen certify our Keycloak environment for SOC 2?

No. DeployOpen does not issue SOC 2 reports, attestations or certifications. An independent CPA firm performs the SOC 2 examination and issues the report. DeployOpen can plan and configure Keycloak, document the access control design, and prepare the evidence an auditor will request, such as configuration exports, role definitions and access review records.

Your organization remains responsible for operating the controls and for deciding the scope of the report. When you request a quote, ask the partner to state in writing which deliverables prepare evidence for the auditor and which steps belong to your team or to the auditor. That split should appear in the scope before work starts.

How DeployOpen scopes and delivers Keycloak SOC 2 access controls

DeployOpen plans, implements, hardens, documents and supports self-hosted Keycloak in your own cloud accounts, data centers or air-gapped networks. For SOC 2 logical access controls, the work maps realm configuration to the CC6.1, CC6.2, CC6.3 and CC6.6 points your auditor will test, and prepares the evidence for that review. DeployOpen does not issue audit reports; your independent auditor does.

How we scope

The written scope names which applications, user populations and realms fall inside the SOC 2 system boundary.
Scope also records which CC6 criteria the engagement addresses and which controls stay with your own teams.
Engagements are fixed-scope, with deliverables agreed in writing before work starts, and support available as a retainer.

How we build

Define roles and groups as least-privilege bundles, with client roles mapped to job functions and reviewed before go-live.
Configure OTP, WebAuthn or passkey policies for access that arrives from outside the system boundary.
Put the admin console and Administration REST API on a separate hostname behind TLS and a path-restricting reverse proxy.

How we hand over

A written access control matrix tying each CC6 point of focus to a realm setting, role or process owner.
Exported realm configuration and a runbook for onboarding, offboarding, role reviews and credential revocation.
An evidence index listing which login and admin events your Keycloak version records and how your team exports them.

How we support

Upgrade planning for Keycloak minor releases, including review of each upgrade note before a change window opens.
Monitoring setup using Keycloak's Prometheus metrics endpoint, enabled on the management interface, so access health stays visible.
Retainers cover ongoing support, upgrades and continuous testing after handover.