Authentication and access control are among the most scrutinized areas in any Aramco CCC audit. SACS-002 controls TPC-2 and TPC-3 define precise requirements for password policies, account lockout, session management, and multi-factor authentication. These are not broad directives -- they specify exact numbers: minimum character counts, password history depth, rotation periods, lockout thresholds, and screen lock timeouts. If your systems do not enforce these specifications at the platform level, the auditor will flag every deviation. This guide breaks down each requirement, explains where vendors commonly fail, and shows how platform-level enforcement eliminates the gap between policy and practice.
TPC-2: Password Policy Requirements
SACS-002 TPC-2 (Access Control): Passwords must be a minimum of 8 characters including special characters, maintain a 12-password history, enforce 90-day maximum age, lock accounts after 10 failed attempts, and activate screen saver lock after 15 minutes of inactivity. Multi-factor authentication is required for all cloud-based access.
TPC-2 is one of the most detail-rich controls in SACS-002. Each parameter is specific and measurable, which means the auditor can verify compliance precisely. Let us examine each parameter individually.
Minimum 8 Characters with Special Characters
Every password across your organization must meet a minimum length of 8 characters and include at least one special character (such as !, @, #, $, %). In practice, most organizations implement a policy requiring a mix of uppercase letters, lowercase letters, numbers, and special characters -- this satisfies the requirement and aligns with industry best practices.
The critical distinction is between having a written policy and having technical enforcement. A policy document stating "passwords must be 8 characters with special characters" is not sufficient. The auditor needs evidence that the system rejects passwords that do not meet the requirements. This means:
- Active Directory Group Policy (for Windows environments) must enforce complexity requirements
- Linux PAM modules (pam_pwquality) must be configured with
minlen=8andocredit=-1(or equivalent) - Email, file hosting, and RDP platforms must enforce the same complexity at the application level
- The auditor will attempt to set a non-compliant password during the review to verify enforcement
12-Password History
Users must not be able to reuse any of their previous 12 passwords. This prevents the common pattern of rotating between two or three "favorite" passwords. The system must store password hashes for at least 12 previous passwords per user and reject any new password that matches a stored hash.
Evidence required: screenshot of the password history setting in your identity management system (Active Directory, LDAP, or application settings).
90-Day Maximum Password Age
Passwords must expire after no more than 90 days. When a password reaches the age limit, the user must be forced to change it before they can access the system. This means:
- The system must track when each password was last changed
- Users must receive a warning before expiration (typically 14 days before)
- After 90 days, the system must force a password change at the next login
- Administrators should not be exempt -- all accounts must follow the same rotation policy
10-Attempt Account Lockout
After 10 consecutive failed login attempts, the account must be locked. This protects against brute-force password attacks. The lockout policy must define:
- Lockout threshold: 10 failed attempts
- Lockout duration: Either a timed lockout (e.g., 30 minutes) or permanent lockout requiring administrator intervention
- Attempt counter reset: How long until the failed attempt counter resets (typically 30 minutes)
The auditor will review the lockout policy configuration and may test it by intentionally entering incorrect passwords.
15-Minute Screen Saver Lock
Workstations must automatically lock after 15 minutes of inactivity. This prevents unauthorized access to unattended workstations. The lock must require re-authentication (password or MFA) to resume the session.
Implementation methods:
- Windows: Group Policy setting for screen saver timeout and "On resume, display logon screen"
- macOS: Require password after sleep or screen saver begins, with screen saver activation after 15 minutes
- Linux: Screen lock configuration in the desktop environment or via
xautolock - RDP sessions: Session timeout configured on the RDP server to disconnect or lock idle sessions after 15 minutes
Password Policy Requirements Table
The following table summarizes each TPC-2 password requirement, the exact SACS-002 specification, and how the MassiveGRID package enforces it at the platform level.
| Password Policy Requirement | SACS-002 Specification | Package Enforcement |
|---|---|---|
| Minimum password length | 8 characters minimum | Enforced on email, file hosting, RDP, and VPN accounts; passwords below 8 characters are rejected |
| Complexity requirement | Must include special characters | All platforms require uppercase, lowercase, numeric, and special characters; non-compliant passwords rejected at input |
| Password history | 12-password history (cannot reuse last 12 passwords) | Password history tracking enforced on all managed services; previous 12 hashes stored and checked |
| Maximum password age | 90-day rotation | Forced password change after 90 days on all accounts; warning notifications at 14 days before expiry |
| Account lockout threshold | Lock after 10 failed attempts | Account lockout triggered after 10 consecutive failures on email, RDP, VPN, and file hosting |
| Screen lock timeout | 15-minute inactivity lock | RDP session idle timeout set to 15 minutes with automatic session lock; re-authentication required |
| Multi-factor authentication | Required for all cloud-based access | MFA enforced on email, file hosting web interface, RDP gateway, and VPN; supports TOTP and hardware keys |
TPC-3: Password Protection on All Assets
TPC-3 extends the password requirement beyond user accounts to every IT asset in your inventory. Every system, device, and application must be password-protected. No system should be accessible without authentication. This includes:
- Servers (physical and virtual)
- Workstations and laptops
- Network equipment (routers, switches, access points)
- Printers and multifunction devices with network connectivity
- IoT devices and sensors
- Mobile devices used for business
The auditor will cross-reference your asset inventory (which you must maintain) with the authentication status of each asset. Any device accessible without a password is a finding.
Common oversight: Network printers and Wi-Fi access points frequently ship with default credentials or no password at all. These are IT assets under SACS-002 and must be password-protected with credentials that meet TPC-2 complexity requirements. Default manufacturer passwords must be changed.
Multi-Factor Authentication: The Cloud Access Mandate
SACS-002 mandates MFA for all cloud-based access. "Cloud-based" in this context means any service accessed over the internet, including:
- Email (webmail, IMAP/POP over internet, mobile email clients)
- File hosting (web-based file management, SFTP over internet)
- Remote desktop (RDP via internet or VPN -- both require MFA)
- VPN access (the VPN connection itself must require MFA)
- Admin panels (hosting control panels, server management interfaces)
- SaaS applications (any business SaaS used for Aramco work)
What Counts as MFA
MFA requires at least two distinct authentication factors from different categories:
- Something you know: Password, PIN
- Something you have: TOTP authenticator app (Google Authenticator, Microsoft Authenticator, Authy), hardware security key (YubiKey, FIDO2), SMS code (accepted but less preferred)
- Something you are: Biometric (fingerprint, face recognition)
A password plus a TOTP code from an authenticator app is the most common MFA implementation and is fully compliant with SACS-002. SMS-based MFA is generally accepted but is considered weaker due to SIM-swapping risks. Hardware security keys provide the strongest MFA and are recommended for privileged accounts.
MFA Must Be Enforced, Not Optional
A critical distinction: MFA must be enforced at the platform level, not merely available for users to enable voluntarily. If MFA is optional and individual users can skip enrollment, the auditor will flag it as non-compliant. The platform must require MFA enrollment for all users and reject login attempts that do not complete the MFA challenge.
Evidence the auditor expects:
- MFA policy configuration showing it is mandatory for all users
- MFA enrollment report showing all active users have enrolled
- Screenshot of the login flow showing the MFA prompt
- For each cloud-based service: proof that MFA is active (email, file hosting, RDP, VPN)
Strong Authentication for Critical Data Access
For CCC+ vendors classified as Critical Data Processors, SACS-002 imposes additional authentication requirements beyond standard MFA:
- Privileged access management (PAM): Administrative and privileged accounts must use stronger authentication than standard user accounts. This may include hardware security keys, certificate-based authentication, or biometric verification in addition to passwords.
- Just-in-time access: Privileged access should be granted only when needed and automatically revoked after the task is completed.
- Session recording: Administrative sessions accessing critical data should be logged and recorded for audit review.
- Access reviews: Regular reviews (at least quarterly) of who has access to critical data and whether that access is still justified.
How Platform-Level Enforcement Works
The fundamental challenge with access control compliance is the gap between policy and enforcement. Writing a password policy takes an afternoon. Enforcing that policy across every system in your environment -- email, file hosting, remote desktop, VPN, workstations, servers -- is an infrastructure project.
Consider a typical vendor environment without centralized identity management:
- Email passwords are managed by the email provider with its own policy settings
- File hosting passwords are managed by the file hosting platform
- RDP passwords are managed by Windows local or domain accounts
- VPN passwords are managed by the VPN server
- Each system may have different password complexity settings, different history depths, different lockout thresholds
Achieving uniform SACS-002 compliance across all these systems requires either a centralized identity provider (Active Directory, LDAP, or an IDaaS platform) or a managed infrastructure package where all services are pre-configured with uniform policies.
Access Control Across RDP, Email, and File Hosting
Let us walk through how SACS-002 access control requirements apply to the three most common cloud-based services in a CCC vendor's environment.
Remote Desktop (RDP)
RDP is typically the highest-risk access point because it provides full desktop access to a server or workstation. For CCC compliance:
- RDP must require MFA at login (typically through an RDP gateway with MFA integration or a VPN with MFA that tunnels RDP)
- Password complexity must be enforced at the Windows domain or local policy level
- Session idle timeout must be set to 15 minutes
- Account lockout must be configured for 10 failed attempts
- RDP should not be directly exposed to the internet -- access through a VPN adds a mandatory second authentication layer
For more on securing RDP connections with encryption, see our SACS-002 encryption requirements guide.
Email access control intersects with the email-specific TPC controls (TPC-8, TPC-9, TPC-10). From an access control perspective:
- Email accounts must enforce SACS-002 password complexity at the platform level
- MFA must be enabled and enforced for webmail and any internet-accessible email protocol (IMAP, ActiveSync)
- Password rotation (90-day) and history (12-password) must be enforced
- Account lockout after 10 failed attempts must be active
File Hosting
Encrypted file hosting (replacing insecure alternatives like Google Drive, Dropbox, or email attachments for sensitive files) must implement:
- MFA for web interface access and SFTP access
- Password complexity enforced at the platform level
- Access logging showing who accessed which files and when
- User permission management with principle of least privilege
Common Access Control Audit Failures
Based on observed patterns in CCC audits, these are the most frequent access control findings:
- MFA not enforced (only available): The service supports MFA, but users are not required to enable it. Some users have MFA, others do not. The auditor flags every account without MFA.
- Password history not configured: The 90-day rotation is enforced, but password history is set to 0 or 1, allowing users to immediately reuse their previous password.
- Different policies on different systems: Email enforces 8-character passwords, but the file hosting platform allows 6-character passwords. The auditor finds the weakest link.
- RDP without MFA: RDP is accessible with password-only authentication, even if accessed through a VPN. Both layers should require MFA for defense in depth.
- Screen lock not enforced on workstations: The policy says 15 minutes, but the Group Policy is not applied to all machines, or laptops taken home have different settings.
- Service accounts without password rotation: Service accounts (used by applications, scripts, or automated processes) are exempt from the 90-day rotation. SACS-002 does not provide such an exemption.
- Default passwords on network equipment: Printers, switches, and access points still use manufacturer default credentials.
Bringing It All Together
Access control is the thread that runs through every other SACS-002 requirement. Your firewall admin panel needs MFA. Your email system needs enforced password policies. Your VPN needs MFA at the connection level. Every component in your CCC compliance infrastructure must implement the same access control baseline defined by TPC-2 and TPC-3.
The most reliable way to achieve uniform enforcement is to use a platform where all services share the same identity and access management layer. When email, file hosting, RDP, and VPN all enforce the same password complexity, the same history depth, the same rotation period, and the same MFA requirement, you eliminate the configuration drift that causes audit findings.
For a comprehensive overview of all SACS-002 requirements, see our complete Aramco CCC guide.
Get Platform-Level Access Control Enforcement
MassiveGRID's Aramco CCC-Compliant Infrastructure Package enforces SACS-002 password policies and MFA across every component -- email, RDP, file hosting, and VPN -- from a single managed platform. Password complexity, 12-password history, 90-day rotation, 10-attempt lockout, 15-minute session timeout, and mandatory MFA are all pre-configured and enforced at the platform level, not left to individual user compliance.
See how the CCC-compliant package enforces access control across every service →