Service accounts are critical in system operations but can be a security nightmare if mismanaged. PCI DSS Requirements 7 and 8 demand strict controls to limit access and ensure accountability, especially for these non-human accounts. Here’s how to nail compliance with a focus on service accounts.
Service accounts mean different things to different people. For PCI, service accounts (also known as application or system accounts) are accounts used only by systems and not humans. These accounts are to be used in the background and not logged in from a keyboard. This would require that the interactive login ability is removed from the account or configured with a non-functional or restricted shell to prevent direct logins.
These accounts are often admin or root equivalent. There are times that level of access is necessary, but in most cases, this elevated permission is not necessary. The accounts should be unique to an application or service and then the permissions for that application or service are all that is granted. The whole idea is to use these accounts to separate the elevated privileges so if one account is compromised, they are an elevated user for one system only, not an admin equivalent on the whole network.
Sometimes these accounts do not have passwords (because they are used behind the scenes). PCI requires each service account has a password. The frequency of changing that password can be longer based on the Targeted Risk Analysis that is performed. A password also cannot be hard-coded in any scripts.
Finding this helpful? Join our newsletter.
Another PCI requirement is to perform an access review that looks at all the permissions assigned to these service accounts. It used to be that admins were trained that service accounts were just created as admin-equivalents or root. This behavior made them great targets, especially if vendors used the same password for their service account on everyone’s systems. That’s where PCI is coming from… no shared passwords on these service accounts (requirement 2.2.2), no excessive privileges, and you have to review those accounts to make sure they only have the permissions they need.
How to begin… inventory of your service accounts. The inventory should include where they are (what server, what container, etc.). Document what they are used for, the account owner, and the permissions they have. Work with each account owner to identify and document what, if any, permissions you can remove. If the service account is an administrator, document the business justification for this level of access. Then look at the account configuration – has interactive login been removed, are password settings in alignment with the Targeted Risk Analysis, history configured so the password cannot be used until 4 other passwords are used, etc. Verify that the account has been configured to restrict the systems it can login from and remote access capability has been removed. An alert should be configured to notify the account owner if this account tries to login from a keyboard. It may be useful to notify the account owner ANYTIME a service account logs in. This way the account owner can identify activity that should be investigated.
Once details about existing service accounts are identified, future access reviews will be easier to complete. Ensure policies and procedures support this activity of service account management. Policies shouldn’t take much effort, but procedures are a little bit more in-depth. Procedures are step-by-step documents that are so detailed that anyone with the proper permissions should produce the same result every time. Maintain procedures for creating system accounts, performing a user access review, setting up alerts for those accounts, etc.
A Targeted Risk Analysis is also needed to document why the frequency of user access reviews was chosen.
Service accounts may be subject to other password policies than the end user accounts. Make sure service accounts comply with all of requirement 7 and 8 (except 8.4.2 which requires multifactor authentication – MFA is not required for service accounts if they are only performing automated functions).
If service accounts are allowed interactive login, PCI requirement 8.6 can be difficult to achieve. This requirement requires that anyone logging in using that service account must be identified. This can be done by using a password management tool that requires the service account password be checked out. The password management tool would then document who checked out the password and then this could be used to track who logged in as the service account. This also requires time restrictions are in place for the account to restrict when the account can be used, documented business justification for the interactive login ability, and documented approvals from management for the interactive login access. In addition, requirement 10.2.1.2 requires all interactive use of service accounts be logged.
In summary, a service account is unique because its meant to operate in the background without human intervention. Service accounts are often created and forgotten. PCI now requires better documented administration of service accounts to ensure better security. Management of service accounts is now a requirement as of March 31, 2025. Don’t wait—contact Auditwerx at [email protected] or visit www.auditwerx.com for expert guidance to comply with these new requirements.
