Comparing MFA and SSO for budgeting access control-security trade-offs

We’re evaluating access control policies for our budgeting module and debating between enforcing MFA on every budgeting session versus relying on SSO with periodic re-authentication. Our finance team needs to access budgeting data frequently throughout the day, and we’re trying to balance security with usability.

MFA would provide stronger authentication but might frustrate users who log in 10-15 times daily. SSO with 8-hour session timeout seems more user-friendly but potentially less secure for sensitive financial data. We’re on R2-2023 and need to comply with SOX requirements.

What approaches have others taken for budgeting module access? Curious about real-world experiences with MFA enforcement frequency versus SSO session management, and how you’ve handled the user experience versus security trade-off.

Both approaches are viable under SOX — the control objective is demonstrable access assurance, not a specific authentication mechanism. The real architectural question is where you place re-authentication friction relative to risk context.


Criteria Comparison

Criteria MFA Every Session SSO + Periodic Re-auth
SOX Compliance Fit Strong — explicit auth event per session, easy audit trail Acceptable — requires session logging and re-auth triggers to be airtight
Security Posture Higher — limits blast radius of compromised SSO token Moderate — 8-hour window is a meaningful exposure period for financial data
User Friction High — 10–15 daily prompts degrades adoption and increases workaround risk Low-to-moderate — single daily auth with contextual step-up
Audit Log Clarity Straightforward — each session has discrete auth event Requires correlating session tokens to user activity windows
Implementation Complexity Lower — single policy applied broadly Higher — session management, token expiry rules, and step-up triggers need tuning
Risk Adaptability Static — same friction regardless of context High — step-up MFA on sensitive actions (e.g., budget publish, mass update)

Workday-Specific Considerations

Workday’s Security Policy framework (verify in your version) supports step-up authentication as a middle path — SSO handles ambient access, but specific Domain Security Policies on high-sensitivity tasks (budget amendments, period close, mass compensation adjustments) trigger MFA at the action level rather than the session level. This maps well to SOX IT General Controls because you can demonstrate that privileged budget modifications require explicit re-authentication, without burdening read-heavy workflows.

Key configuration touchpoints:

  • Authentication Policies — define MFA conditions per security group or named domain
  • Session Timeout settings — configurable per environment; 8 hours is common but consider 4 hours for finance roles (verify current max/min in your tenant)
  • Workday-owned audit reports — Audit Trail and User Activity Logging domains need to be mapped to your SOX evidence package regardless of auth method

Practical SOX framing: Your external auditors will ask for evidence of who accessed what and when. SSO with solid session logging often satisfies this — but if your auditors expect a discrete auth event per sensitive transaction, step-up MFA on budget write-domains is the cleaner control to evidence.

One operational risk worth flagging: heavy MFA friction increases credential-sharing behavior among finance staff under deadline pressure — which directly undercuts the control you’re trying to enforce.


The right answer depends on your auditor’s control expectations, your identity provider’s step-up MFA capabilities, and the ratio of read vs. write activity your finance team performs daily — depends on context / your requirements.


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.

We implemented adaptive MFA - it only prompts for additional authentication when users access budgeting from new devices or locations. Regular access from known devices uses SSO with 4-hour timeout. This reduced MFA prompts by 80% while maintaining security for anomalous access patterns. Users are much happier, and we still meet audit requirements.

From a SOX perspective, you need to demonstrate strong authentication for financial system access. We use SSO with step-up authentication - normal browsing doesn’t require MFA, but any write operations in budgeting (creating, modifying, approving budgets) trigger MFA challenge. Read-only access uses SSO only. This gives you audit trail showing MFA for sensitive operations without annoying users for every login.

Consider your user personas carefully. Budget analysts who live in the system all day need different treatment than executives who check quarterly budgets. We segment users by role and apply different policies - analysts get longer SSO sessions (8 hours) with weekly MFA, executives get shorter sessions (2 hours) with more frequent MFA since they access less often anyway.

The adaptive MFA approach sounds promising. How do you define ‘known devices’ in Workday? Is this based on browser fingerprinting or something more robust? And does it work reliably when users switch between office and remote work?

Device trust is managed through your identity provider (Okta, Azure AD, etc.), not Workday directly. The IdP maintains device registration and certificate-based trust. When a user authenticates from a registered device, the IdP passes a trust claim to Workday via SAML assertion. Workday then honors the SSO session without additional MFA challenge. For remote work, VPN connection can be a trust signal, or use conditional access policies based on IP ranges.

From the user side, I’ll say constant MFA prompts are productivity killers. Our team lost an estimated 15-20 minutes per day just dealing with authentication interruptions before we adjusted policies. Whatever you choose, make sure it doesn’t break workflow for power users who need continuous access during month-end close periods.

After implementing similar policies across multiple Workday deployments, here’s my comprehensive analysis of all three focus areas:

MFA Enforcement Frequency: The optimal approach is risk-based adaptive MFA rather than blanket enforcement. Implement tiered policies:

  • Tier 1 (Power Users): MFA at login, then SSO for 8 hours with step-up authentication for high-risk operations (budget approval, mass updates)
  • Tier 2 (Occasional Users): MFA every 4 hours or when accessing from new location/device
  • Tier 3 (Executives): MFA on every session due to high-privilege access and infrequent usage patterns

Key metric: MFA should challenge <5% of daily interactions for power users while covering 100% of sensitive operations. Use Workday’s security policies to define what constitutes ‘sensitive’ - typically create/modify/approve actions rather than read-only queries.

SSO Session Management: SSO sessions should vary by user context and risk profile:

  • Session timeout: 4-8 hours for active users, 1-2 hours for privileged accounts
  • Idle timeout: 30 minutes of inactivity triggers re-authentication
  • Session extension: Allow seamless extension during active work, but require re-auth after idle period
  • Token refresh: Background token refresh prevents interruption during active sessions

Critical consideration: Align Workday session timeouts with your IdP settings. Mismatched timeouts cause user confusion when SSO works but Workday session expired.

User Experience vs Security Trade-off: The balance depends on your organization’s risk appetite and regulatory requirements. Best practices:

  1. Context-aware policies: Use device trust, location, time-of-day, and behavior analytics to adjust authentication requirements dynamically
  2. Transparent security: Users should understand WHY they’re being challenged (“Approving $500K budget requires additional verification”)
  3. Frictionless MFA: Push notifications or biometric authentication significantly improve UX over SMS codes
  4. Grace periods: During month-end close (high-activity periods), consider temporarily extending session timeouts with enhanced logging
  5. Audit evidence: Maintain detailed logs showing authentication events, session duration, and operations performed to satisfy SOX auditors

For SOX compliance specifically, focus on demonstrating:

  • Strong authentication for financial data modification (MFA required)
  • Segregation of duties (different roles, different policies)
  • Complete audit trail (who accessed what, when, with what authentication method)
  • Regular access reviews (quarterly certification of budgeting access)

Recommendation: Start with SSO + adaptive MFA. Monitor user feedback and security events for 90 days, then adjust thresholds. Most organizations find 8-hour SSO sessions with step-up MFA for sensitive operations provides the best balance. This satisfies auditors (strong auth where it matters) while keeping users productive (minimal interruption for routine work).