We recently updated our security policies in Workday R1 2024 and now users working in subscription management are complaining about being logged out constantly. The session timeout appears to be set far too short - they’re getting kicked out every 15-20 minutes even during active work. We’ve checked our SSO provider configuration (Okta) and the idle timeout there is set to 2 hours, so the problem seems to be on the Workday side. This is severely impacting productivity as subscription coordinators have to re-authenticate multiple times per hour while processing renewals. Has anyone else encountered this after a security policy update? What’s the recommended approach to balance security with usability here?
I’ve dealt with this exact scenario multiple times across different Workday implementations, and the key is understanding how all three timeout mechanisms interact after a security policy update.
First, let’s address the SSO provider configuration you’ve already checked. Your Okta idle timeout of 2 hours is correct, but you also need to verify the Okta session lifetime (not just idle timeout) and ensure token refresh is enabled. This is critical for maintaining seamless authentication.
For the Workday session timeout issue, here’s the comprehensive solution addressing all three areas:
Security Policy Configuration: Navigate to System Security > Security Configuration > Session Management. You’ll find the tenant-wide default is likely set to 30 minutes post-update. However, don’t just increase this globally.
Granular Timeout by Security Group: Go to System Security > Security Configuration > Session Timeout by Security Group. Create differentiated policies:
- Subscription Management Users: 90 minutes (active session) / 120 minutes (absolute)
- Finance/Admin Users: 45 minutes (active session) / 60 minutes (absolute)
- Privileged Administrators: 30 minutes (active session) / 30 minutes (absolute)
This addresses the ‘session timeout too short’ concern while maintaining security controls.
SSO Token Synchronization: In your Okta integration configuration within Workday (System > Security > SSO Configuration), verify:
- SAML assertion lifetime matches or exceeds your longest Workday session timeout
- Token refresh is enabled (critical for seamless re-authentication)
- Session policy enforcement is set to ‘Workday and SSO provider’ not ‘SSO provider only’
Testing Protocol: After making changes, test with actual subscription management users. Monitor the session activity logs (System > Audit > User Activity) to confirm sessions are maintained for the expected duration. Also verify that SSO token refresh happens transparently without forcing re-authentication.
Audit Compliance Note: Document your rationale for differentiated timeouts in your security policy. Auditors accept risk-based timeout policies when properly justified - operational users processing high-volume transactions need longer sessions than privileged administrators who should be monitored more strictly.
This approach balances security requirements with user productivity and ensures all three components (security policy, session timeout, SSO provider) work together cohesively.
This draft is based on general Workday knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check your Workday tenant security settings under System Configuration. There’s a separate session timeout parameter specifically for web sessions that might have been changed during your policy update. It’s independent of your SSO provider’s timeout.
This is a common issue after security hardening. The session timeout in Workday can be configured at multiple levels - tenant-wide, by security group, or even by specific functional areas. Since you mentioned subscription management specifically, I’d also look at whether there are any custom security policies applied to that module. Sometimes organizations set shorter timeouts for financial modules without realizing the productivity impact. The standard recommendation is 60-90 minutes for active sessions with proper idle detection.
Thanks both. I found the tenant-wide setting and it’s currently at 30 minutes. That explains the issue. However, our security team is pushing back on extending it beyond 45 minutes. Is there a way to set different timeouts for different user groups? Our subscription team needs longer sessions but we want tighter controls for admin users.
Yes, you can configure session timeouts by security group. Navigate to System Security > Security Configuration > Session Timeout by Security Group. Create entries for your different user populations. We have 90 minutes for operational users and 30 minutes for privileged admin accounts. Just make sure to document this in your security policy documentation for auditors.
One thing to add - make sure your SSO token refresh is properly configured. Even with longer Workday session timeouts, if your SSO tokens aren’t refreshing correctly, users will still get kicked out. We had this exact scenario and it turned out to be a token lifetime mismatch between Okta and Workday.