·

Workday Security

·

Josh Santinon

10 Workday security level-ups worth doing this quarter

Ten practical Workday security checks that go beyond the standard implementation checklist, covering everything from piping the User Activity Report into your SIEM, to IP restricting admin and API access, to catching toxic approval flow combinations before they become a real problem. None of them are complicated individually, but they're the kind of thing that gets set once and never revisited until an audit or incident forces the question.

Professionals reviewing an integration plan

10 Workday security level-ups worth doing this quarter

Authentication and security configuration is one of those areas that gets set up once during implementation and rarely revisited, right up until an audit or an incident makes everyone suddenly very interested in it. None of the ten below are complicated on their own. What they have in common is that they're easy to leave half-done, or to forget entirely once the project team has moved on.

1. Plug the User Activity Report into your SIEM

Workday's User Activity Report is a genuinely useful source of truth for anyone monitoring your tenant, but most businesses never connect it to where their security team is actually watching. Microsoft Sentinel has a connector for this, which makes the integration itself straightforward. The real work is on the other side: you'll need to spend some time clearing out the noise so you're only exposing what you actually want visibility on, or building a custom report off the User Activity Report to get there. Skip that step and you'll end up with a feed nobody looks at.

2. Restrict admin activity to your VPN's IP range

Most businesses already run a VPN. Fewer businesses actually use their authentication policy to enforce it for the people who matter most. Workday's RBAC model gets you most of the way there on its own, but layering in an IP restriction ensures admin and configuration activity is only happening from business VPN enabled devices, not just from accounts with the right role assigned. Constraining admin and configurator activity so it can only happen from your VPN's IP range means the people with the most access in your tenant are also the people with the tightest access controls around them.

3. IP restrict the APIs being called by third parties

The same logic applies on the integration side. Restricting API access by IP range blocks access attempts from sources you weren't expecting, and it works especially well if you go a step further and split access per calling system, or per business case, rather than leaving every third party integration point open to the same broad range.

4. Restrict your implementers' IP ranges too

This one's an added layer rather than a primary control, but it's cheap to put in place. Restricting implementer access by IP range reduces the risk of malicious access originating from outside an implementer's own company devices, or of an implementer's account being compromised and accessed by someone else entirely.

5. Turn on risk based authentication

Workday will evaluate sign-in attempts against known malware originators and assign a risk score accordingly, with known bad sources landing at the top end, think a score around 99. Under the hood it's assessing internet traffic headers, session characteristics, and browser signals statistically to judge whether traffic looks like it's coming from a malicious source. Access can still be granted in every case, so this isn't a hard block, it's a metric you start building visibility against your sign-ins with.

A few compatibility points worth knowing before you turn it on: it doesn't support proxy login, WebAuthn, or OIDC authentication, it doesn't distinguish between a user's personal and work email address when calculating a risk score, and it isn't available for candidates. It does support SAML login, so if that's your primary authentication method, there's little reason not to enable it.

6. Go easy on step-up authentication

This is more of a caution than a switch to flip. In my experience, genuine use cases for step-up authentication are minimal, and it tends to only make sense for admins and configurators, who should already be a small population if your access model is sound. Beyond that group, both implementing and experiencing step-up authentication is frustrating at best.

7. Set a real calendar reminder to refresh your integration keys

Workday will send you reminder notifications when keys are approaching expiry, but relying on those alone is how keys get forgotten. Tie a refresh cadence into your existing integration schedule reviews instead. I'd suggest setting your own reminder at eleven months from the last refresh, done annually, since it often means reaching out to downstream or upstream system owners ahead of time, not just rotating a key on your own side.

8. Store sandbox integration keys in production

Every week, production data copies down to sandbox. If your sandbox integration keys aren't also stored in production, you're stuck reconfiguring them weekly, or every time you need to test. It sounds riskier than it is. Keys are stored securely regardless, and depending on the key type they're either password protected, one-time view and should be sitting in a vault platform, or a public key, which is low risk by nature.

9. Review approval flows for toxic combinations through inheritance

I'll never forget a conversation with a colleague about this one. In a previous role, he was part of investigating a misuse of company funds, and traced it back to a manager who was, in effect, in charge of approving their own expenses. The reporting structure had hierarchically incentivised approval rather than scrutiny. A few houses and car purchases later, funnelled through a bucket company, that manager was gone and the process was remediated.

When you're setting up approval flows in Workday, it's worth specifically reviewing whether any toxic combinations can emerge through inheritance, particularly situations where someone temporarily or permanently inherits their manager's approval authority while that manager is away or has left the business.

10. Check whether your ISUs allow UI sessions

This tends to show up more in legacy tenants, but it's worth double-checking regardless. Disabling UI sessions for Integration System Users forces the removal of a password and means only keys can be used to access the account. There shouldn't be a genuine use case for logging in as an ISU through the UI, so if that's still enabled somewhere in your tenant, it's an easy one to close off.

The common thread

None of these ten are individually complicated, and most take an hour or less to check or configure. What they have in common is that they're easy to set once and never revisit, right up until the gap they left open turns into a real problem. A regular pass through this list, even once or twice a year, catches drift before someone else finds it for you.

Need help with integrations that have become harder to support?

Santinon Consulting brings practical experience to the design, remediation, and handover of Workday integrations.