8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.
Defined Approach Requirements
8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.
Customized Approach Objective
A user session cannot be used except by the authorized user.
Applicability Notes
This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
This requirement is not meant to prevent legitimate activities from being performed while the console/PC is unattended.
Defined Approach Testing Procedures
8.2.8 Examine system configuration settings to verify that system/session idle timeout features for user sessions have been set to 15 minutes or less.
Purpose
When users walk away from an open machine with access to system components or cardholder data, there is a risk that the machine may be used by others in the user's absence, resulting in unauthorized account access and/or misuse.
Good Practice
The re-authentication can be applied either at the system level to protect all sessions running on that machine or at the application level.
Entities may also want to consider staging controls in succession to further restrict the access of an unattended session as time passes. For example, the screensaver may activate after 15 minutes and log off the user after an hour.
However, timeout controls must balance the risk of access and exposure with the impact to the user and purpose of the access.
If a user needs to run a program from an unattended computer, the user can log in to the computer to initiate the program, and then "lock" the computer so that no one else can use the user's login while the computer is unattended.
Examples
One way to meet this requirement is to configure an automated screensaver to launch whenever the console is idle for 15 minutes and requiring the logged-in user to enter their password to unlock the screen.
purpose
Authenticate all access to system components using at least one authentication factor.
compliance strategies
- Password, token, or biometric authentication
typical policies
- Authentication Policy
common pitfalls
- No authentication for some access methods
type
Technical Control
difficulty
Low
key risks
- Unauthorized system access
recommendations
- Audit all authentication paths
Eligible SAQ
- SAQ-A-EP
- SAQ-C
- SAQ-D MERCHANT
- SAQ-D SERVICE PROVIDER
Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below. Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy