SOC 2 Access Control for On-Premise and Bare Metal Environments

In cloud environments, access control is a managed service. AWS IAM provides centralized identity, Okta handles SSO across every SaaS tool, and the entire access lifecycle is API-driven. Provision a user, assign a role, revoke on termination. The access model is clean because the platform was designed that way.

On-premise environments don't have that luxury. The identity layer is Active Directory running on a dedicated server. Some systems join the domain, others don't. Network appliances have their own local accounts. Database servers have SQL logins that may or may not align with AD. The VPN has its own certificate-based authentication, and the bastion host sits between everything.

This post covers how to implement and evidence SOC 2 access controls in on-premise environments, from centralized identity through quarterly reviews. It's part of a broader series on SOC 2 readiness for bare metal and on-prem infrastructure.

What SOC 2 Expects for Access Control

The auditor isn't looking for a specific technology. They're looking for a system where access is controlled, attributable to individuals, reviewed periodically, and revoked promptly when someone leaves.

Centralized Identity: Active Directory and LDAPS

Active Directory remains the backbone of identity management in most on-premise environments. For SOC 2, it serves as the central directory that auditors use to understand who has access to what.

AD as the Identity Source of Truth

A production-dedicated AD server provides centralized authentication and authorization for internal staff. Windows servers join the domain and inherit Group Policy Objects (GPOs) for password enforcement, idle timeout, and access restrictions. The bastion host authenticates against AD, creating a single identity layer for administrative access.

For SOC 2 evidence, the AD user listing becomes a primary artifact. An export showing username, display name, account status (enabled/disabled), and last logon date gives the auditor a snapshot of the identity population. Combined with the RBAC matrix, it demonstrates that each account maps to a named individual with a defined role.

LDAPS for Secure Authentication

Systems that support LDAP integration should connect to AD over LDAPS (LDAP over TLS) rather than plain LDAP. This encrypts authentication traffic between the application and the directory, satisfying CC6.1 requirements around protecting authentication credentials. The configuration itself serves as evidence, showing that authentication traffic is encrypted in transit.

Systems That Don't Join AD

Not every system in an on-premise environment supports Active Directory integration. Network appliances (switches, firewall appliances), certain database servers, and legacy applications often maintain their own local account directories.

For these systems, the approach is straightforward:

• Unique local accounts for each administrator, not shared generic accounts
• Password policies enforced locally that align with the organizational standard (NIST 800-63B recommends 8 characters with MFA or 15 characters without)
• Documentation of which systems use local accounts and why AD integration isn't available

The Shared Account Problem

Shared accounts are one of the most common findings in on-premise SOC 2 audits. Auditors will specifically request an export of shared accounts and expect to see an audit trail that attributes activity to individuals.

For teams not ready for full PAM deployment, the minimum requirements are:

• Account documented in a shared account inventory with business justification
• Credentials stored in a password manager with access logging enabled
• Audit logs demonstrate each use is attributable to a specific individual
• Credentials rotated after each use
• Inventory reviewed and re-approved at least annually

Named individual accounts should be the default. Shared accounts should be the documented exception, ideally managed through PAM, or at minimum through a password manager with strict access logging.

The Access Path: VPN, MFA, and Bastion Host

In cloud environments, administrative access flows through the cloud provider's console with IAM roles and MFA. In on-premise environments, the access path needs to be architecturally defined and consistently enforced.

VPN as the Front Door

The VPN gateway is typically the sole entry point to the on-premise environment from the Internet. A well-configured VPN for SOC 2 includes:

• Multi-factor authentication combining at least two independent factors. A strong implementation uses a device certificate (something you have), a PIN or password (something you know), and a TOTP token via an authenticator app (something you have). Three factors at the perimeter means MFA doesn't need to be enforced again on every individual system behind the VPN, though this should be documented as a deliberate architectural decision.
• Individual certificates issued per user, not shared certificates. The VPN certificate listing (showing CN, serial number, assigned user, and issuance date) becomes direct evidence for CC6.1.
• Certificate rotation on a defined schedule, tested annually.

Bastion Host as the Mandatory Gateway

For administrative access, the bastion host (or jump server) sits between the VPN and production systems. It's the only system authorized to reach production servers via RDP, SSH, or equivalent protocols. Firewall rules should explicitly block direct administrative access from any source other than the bastion host.

The bastion host architecture converts what could be a complex web of direct server connections into a single, auditable access path. This is the on-premise equivalent of AWS Session Manager or Azure Bastion.

RBAC: Defining Who Gets What

SOC 2 CC6.2 and CC6.3 require that access is provisioned based on authorization and aligned with job responsibilities. A formal RBAC (Role-Based Access Control) matrix is the cleanest way to demonstrate this.

Building the Matrix

Each role defines the baseline access that should exist. Anything beyond the baseline requires a ticket with justification and approval.

Evidence That Works

The RBAC matrix itself is a primary evidence artifact for CC6.3. Pair it with:

• Management sign-off showing the matrix was reviewed and approved
• Onboarding tickets that reference the matrix when provisioning access
• Exception tickets for any access that deviates from the standard role

This gives the auditor a complete picture: the policy (matrix), the process (provisioning via tickets), and the evidence (approved tickets referencing the matrix).

Password Policies Across Heterogeneous Systems

One of the unique challenges of on-premise SOC 2 is enforcing consistent password policies across systems with different capabilities.

Per-System Evidence

The evidence is different for each system type, but the standard is consistent. This is exactly the kind of deliberate, documented approach that satisfies auditors.

Quarterly Access Reviews

SOC 2 CC6.2 expects periodic validation that access remains appropriate. Annual reviews are the minimum, but quarterly reviews demonstrate stronger control operation, especially during a Type 2 observation period.

The Review Process

Idle and Dormant Account Management

Accounts that haven't been used in months are a common audit finding. SOC 2 CC6.2 expects that access is removed when no longer needed, and idle accounts are a visible indicator of potential gaps.

Automated controls: For application-level accounts (end users), automated idle account disabling is the strongest control. A configurable inactivity threshold (typically 180 days) that automatically disables accounts creates continuous evidence without manual effort.

Manual controls: For infrastructure accounts (AD, VPN, bastion), the quarterly access review should specifically flag accounts with no recent logon activity. AD's last logon attribute and VPN connection logs provide the data needed to identify these accounts.

Bringing It Together: The STEPP Lens

What Makes This Different From Cloud

Cloud IAM is centralized by design. One console, one set of roles, one audit log. On-premise access control requires assembling the same coherent model from multiple independent systems, each with its own authentication mechanism and evidence format.

The work is more manual, but the result can be equally strong. In some ways, on-premise access models force more deliberate design decisions. Every access path is architectural, not just a checkbox in a console. The bastion host pattern creates a cleaner audit trail than many cloud environments where administrative access flows through multiple paths.

Companies running on-premise infrastructure can still use compliance automation platforms for the identity-related controls that have integration points: endpoint management, HR system onboarding triggers, and directory service monitoring. The platform won't replace the quarterly review or the per-system password evidence, but it will centralize what it can reach.

What Comes Next

Access control intersects with nearly every other SOC 2 domain. The network security controls that enforce the bastion host architecture, the vulnerability scanning that runs on systems these accounts access, and the logging architecture that records what these accounts do are all part of the same program.

Next in this series: backup and disaster recovery for on-premise infrastructure, where the evidence model shifts from access logs to restoration testing and offsite transfer verification.

Frequently Asked Questions