As security professionals, it’s interesting to reflect on what really keeps us up at night: customer data, production environments, and access to source code. Here’s a question - where are HR and Finance systems on your list?
We’d all agree they’re important, of course. But, especially for many of us with technical backgrounds, they often take a bit of a back seat. Maybe it’s because systems in our “home field” are ones where we appreciate more of the complexity, or maybe because we expect them to behave as just another tile on the SSO portal, playing nicely with our Identity Provider.
But Workday isn't just another app. In fact, Workday’s security model extends beyond many of the boundaries we commonly think about for SaaS apps. It has its own powerful, complex, and often invisible security model running under the hood - for good reason - and it can be misconfigured in ways your IdP will never see.
And yes, it’s a very valuable target, and a common target too - as we’re seeing in the wild. It holds sensitive people data: PII, payroll, bank accounts, and the entire org chart. Reports by the State of New Jersey, Brown University, and Washington University demonstrate a concerning trend: attackers are actively leveraging weak identity controls to change direct deposit information. This allows them to steal employee paychecks, providing them with easy access to funds.
So, let's look into some of the unique challenges in securing Workday, and talk about how we can close them for good.
The Lifecycle Gap: When Users Exist Before and After Employment
For most SaaS applications, access is typically tied to the user's lifecycle within the company (Joiner-Mover-Leaver). Workday breaks most of these assumptions.
Workday's user lifecycle extends beyond the typical hire-to-fire timeline. Former employees need to access it to retrieve tax documents (like W-2s) and final pay stubs. Pre-hired employees are often also granted access to complete onboarding tasks. This creates standing access paths that bypass your standard IdP lifecycle management. For a similar reason, access to these accounts happens outside the normal corporate SSO, rather using a username-password combination (with/without MFA).
When managed properly, this is fine - and Workday indeed gives you tools specifically for this purpose, such as the Terminee as Self security group. Nevertheless, this breaks many assumptions that apply to most SaaS applications, and can result in severe gaps if not configured properly.
For instance, when thinking about most SaaS applications, when the application is set to redirect to the Identity Provider on authentication attempts, there is no longer a way to authenticate directly to it. In Workday, however, for the reasons described above, it's still possible to access the local authentication page, bypassing SSO (e.g., wd5.myworkday.com/company/login.htmld?redirect=n). If credentials are mismanaged, or this native login path doesn't have MFA enforced within Workday, this can create a backdoor that negates your primary IdP security. An attacker with a leaked password can walk right in.
A Labyrinth of Permissions
Workday's permission model is incredibly granular and powerful, built around roles and business processes. This is necessary for its function, but it's designed for and managed by HR and Finance teams - often being a blind spot for IT and security teams.
Having no visibility into this critical permission structure, not knowing what privileged roles there are, and who holds them, means no ability to properly reason about how to secure them.
This problem is exacerbated by the existence of Integration System Users (ISUs, Workday's terminology for Service Accounts). These accounts create significant challenges:
- Who can create them - Often unclear delegation of ISU creation rights
- What privileges they hold - Excessive permissions that accumulate over time
- Who holds their credentials - Shared or unmanaged access to service account keys
This can lead to a widespread "shadow admin" issue. A user who needed special access for a one-off project three years ago might still have it. These risks can persist for years, with no ability to identify or remediate them, until they’re exposed by a breach.
Authentication Policies as Complex as Your IdP
Many SaaS apps are set up with a simple authentication policy: “Defer to the Identity Provider”. Workday, however, contains its own rich and complex authentication policy engine that can enforce its own rules for who gets in.
Workday allows for highly contextual access decisions to be made natively. You can build rules based on network location, device posture, and user roles, and allow or deny authentication types and methods based on them.
This makes sense in scenarios like:
- Extended user lifecycles - Former employees accessing W-2s, pre-hires completing onboarding
- Context-sensitive access - Restricting public Wi-Fi users to self-service tasks only
- Multi-IdP environments - Organizations using Hub-and-Spoke identity models
Of course, being able to configure such policies isn’t a bad thing. But the existence of those policies outside of the visibility of the security team, and the lower scrutiny that might apply to them in comparison to ones in the Identity Provider, can create security risks if improperly configured. For instance, a policy intended to be used for users outside of the workforce, allowing access without using SSO, might accidentally be applied to other users as well.
From Reactive to Proactive: Securing Workday with Okta ISPM
This brings us to the core problem behind all of these issues: You can't secure what you can't see.
Being tasked with securing the entire organization necessitates having clear visibility to Workday. That means being able to understand the security model behind it, run reports, audit permissions, and even analyze the authentication policies.
This visibility challenge is exactly what Okta Identity Security Posture Management (ISPM) solves. Rather than leaving security teams blind to Workday's internal permission structure, ISPM continuously monitors your tenant, transforming Workday's complex identity maze into a clear, single pane of glass.
It moves your security stance from reactive to proactive by allowing you to:
- Eliminate Blind Spots: ISPM provides a 360° view of every identity. It doesn't just see "active users" - it monitors former (terminated) employees, local users not sourced from the Identity Provider, and automated Integration System Users (ISUs). This ensures that standing access paths don't go unnoticed.
- Enforce "Least Privilege": ISPM identifies overprivileged accounts - both human users and ISUs - by mapping their access to specific data domains. This allows you to spot those service accounts with admin rights from three years ago, and revoke their access before it becomes a liability.
- Detect and secure Non Human Identities: ISPM auto-detects human-born Service Accounts and Integration System Users (ISUs) in your Workday. ISPM immediately shows what access they have, detects unrotated credentials, elevated permissions and inactive accounts.
- Reduce the Attack Surface: ISPM automatically flags accounts with weak authentication policies (e.g., old passwords or missing MFA) and pinpoints unused or orphaned accounts that pose an immediate security risk.
The net result is a highly secure, compliant, and continuously monitored Workday environment.
Ready to eliminate identity blind spots across your most critical applications?
Workday ISPM integration is available now as Early Access. Contact your Okta representative to learn how ISPM can bring modern security insights to your most critical identity infrastructure, learn more at okta.com/products/identity-security-posture-management.
