Workday Data Breach: CRM Security Guide | SalesforceTutorial

Workday data breach is a security topic Salesforce admins should treat as a CRM access-review reminder, not as proof that every Salesforce org was compromised. Workday stated that threat actors reached information in a third-party CRM platform through a social engineering campaign, while also stating that it had no indication of access to Workday customer tenants or tenant data. The practical lesson for Salesforce teams is clear: review identity controls, connected apps, OAuth sessions, integration users, and user training before a phone call or text message becomes an access path.

A Workday data breach response should avoid blame-first language and focus on evidence: users, apps, tokens, permissions, logs, and data scope.

This guide explains what is known from public statements, what Salesforce professionals should not assume, and how to audit a CRM org after similar social engineering activity. It is written for admins, developers, architects, and security reviewers who need a response checklist they can use in production.

Workday Data Breach: What happened?

Workday published an update about a social engineering campaign that targeted large organizations, including Workday. In that update, Workday said attackers contacted employees by phone or text while pretending to represent HR or IT. Workday also said the actor accessed some information from a third-party CRM platform and that the exposed information was mainly business contact data, such as names, email addresses, and phone numbers. Read the original Workday update here: https://blog.workday.com/en-us/protecting-you-from-social-engineering-campaigns-update-from-workday.html.

The Workday data breach matters to Salesforce professionals because a Workday data breach style CRM incident can involve contact records, support history, sales activity, partner details, and integration credentials. Even when the exposed data looks like ordinary contact information, attackers can use it to make the next phishing attempt more believable.

Do not reduce the incident to one vendor name. The pattern is broader: attackers target people, OAuth approvals, third-party apps, and support processes. Salesforce published guidance for defending against social engineering, including login restrictions and identity controls, at https://www.salesforce.com/blog/protect-against-social-engineering/.

What should Salesforce teams learn from the Workday data breach?

For Salesforce teams, the Workday data breach is a reminder that CRM security depends on both platform controls and operating discipline. A secure org can still face risk when a user authorizes the wrong app, approves a malicious request, shares a verification code, or accepts instructions from a caller who sounds legitimate.

In enterprise orgs, the first response to a Workday data breach report should be a controlled review, not panic. Separate these questions:

How to audit connected apps after the Workday data breach

A Workday data breach review should start with connected apps because they are a common place where CRM access can outlive the original user interaction. Salesforce describes connected apps as a framework for integrating external applications with Salesforce using protocols such as OAuth, SAML, and OpenID Connect. See the official overview: https://help.salesforce.com/s/articleView?id=xcloud.connected_app_overview.htm&type=5.

1. Open Connected Apps OAuth Usage. In Setup, search for Connected Apps OAuth Usage. Review apps with active OAuth connections. Salesforce documents that this page lets admins view current OAuth app connections and revoke access where needed: https://help.salesforce.com/s/articleView?id=xcloud.connected_app_manage_current_sessions.htm&type=5.
2. Remove unknown or unused apps. Do not keep an app because “someone might need it.” Find an accountable owner, business purpose, integration user, and data scope. If you cannot find them, remove or block the app after change-control approval.
3. Review OAuth scopes. Broad scopes increase exposure. The app should request only the access needed for its purpose. Salesforce explains OAuth tokens and scopes here: https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_tokens_scopes.htm&type=5.
4. Tighten app policies. For each approved app, define who can use it, what IP restrictions apply, and how refresh token policy should work. Salesforce documents connected app OAuth access policies at https://help.salesforce.com/s/articleView?id=xcloud.connected_app_manage_oauth.htm&type=5.
5. Revoke risky sessions. If an app is suspicious, revoke OAuth access first, then rotate secrets or disable users as needed. Password resets alone do not always remove app authorization that already exists.

For a deeper setup walkthrough, see our related guide to Salesforce connected app configuration.

How should admins check Salesforce identity and access controls?

The Workday data breach shows why CRM teams need layered access controls. A caller who convinces one employee should not gain broad CRM access. Check these areas in order:

• MFA and session assurance: Require multi-factor authentication for interactive logins and higher-risk access paths. Do not rely on passwords alone.
• Trusted IP ranges and login restrictions: Use network controls where your business model allows them. Salesforce’s social engineering guidance lists login ranges and trusted IPs as protective controls.
• Profiles and permission sets: Remove old broad-access profiles. Use permission sets and permission set groups to assign access by job function.
• Integration users: Use dedicated integration users with least-privilege permissions. Do not let integrations run as a full-system admin unless Salesforce Support or a documented vendor requirement leaves no alternative.
• Field-level security: Verify that sensitive fields are not exposed through a user profile just because page layouts hide them.
• Security Health Check: Review baseline security settings in Salesforce Setup. Salesforce documents Health Check at https://help.salesforce.com/s/articleView?id=xcloud.security_health_check.htm&type=5.

In a production org, document every exception. “Temporary” broad access often becomes permanent after the incident call ends.

How to secure Workday, Salesforce, and HR integrations

The Workday data breach also raises integration governance questions. Many enterprises integrate Workday with Salesforce through middleware, file transfer, API services, iPaaS tools, or support workflows. The security question is not only whether Workday or Salesforce is safe. The question is whether the integration boundary has a clear owner, a limited data contract, and monitored credentials.

Use named credentials for outbound Salesforce callouts

When Apex calls an external service, use a Named Credential instead of hardcoding endpoints, usernames, tokens, or secrets. Salesforce’s Apex Developer Guide states that a named credential stores the endpoint URL and authentication details in one definition: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_callouts_named_credentials.htm.

Prefer external client apps for new API patterns where they fit

Salesforce documents External Client Apps as a current approach for API integrations using OAuth 2.0. Trailhead explains that an external client app can separate developer configuration from admin policies, which helps enterprise teams assign clearer ownership: https://trailhead.salesforce.com/content/learn/modules/external-client-app-basics/use-external-client-apps-when-connected-apps-wont-do.

Keep a data contract for each integration

Write down the object list, field list, direction of data movement, authentication method, token rotation owner, and failure process. For Salesforce APIs, start with our Salesforce API integration guide and keep the contract in the same repository as deployment notes or architecture decision records.

Apex example: notify a security system after CRM review

The following Apex example does not investigate the Workday data breach by itself. It shows a safe pattern for sending a reviewed incident note from Salesforce to a SIEM or ticketing system after an admin has already confirmed the facts. The class uses a Queueable job, implements Database.AllowsCallouts, and relies on a Named Credential called Security_SIEM. Set the class API version to v60.0 or later for current orgs unless your package policy requires a different version.

public with sharing class CrmSecurityIncidentJob implements Queueable, Database.AllowsCallouts {
    private final String incidentRef;
    private final List<String> completedActions;

    public CrmSecurityIncidentJob(String incidentRef, List<String> completedActions) {
        this.incidentRef = incidentRef;
        this.completedActions = new List<String>();
        if (completedActions != null) {
            this.completedActions.addAll(completedActions);
        }
    }

    public void execute(QueueableContext context) {
        if (String.isBlank(incidentRef)) {
            return;
        }

        Map<String, Object> payload = new Map<String, Object>{
            'source' => 'Salesforce',
            'category' => 'CRM_SOCIAL_ENGINEERING_REVIEW',
            'reference' => incidentRef,
            'actions' => completedActions,
            'reportedAt' => System.now()
        };

        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:Security_SIEM/incidents');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');
        req.setTimeout(10000);
        req.setBody(JSON.serialize(payload));

        HttpResponse res = new Http().send(req);
        if (res.getStatusCode() >= 300) {
            throw new SecurityNotificationException('SIEM notification failed: ' + res.getStatus());
        }
    }

    public class SecurityNotificationException extends Exception {}
}

Governor limit note: Salesforce documents a limit of 100 HTTP or web service callouts in a single Apex transaction. This job makes one callout and avoids SOQL in loops. For official limits, see https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_callouts_timeouts.htm.

A deployment-ready version also needs tests. Salesforce requires Apex tests to pass and at least 75% code coverage for deployment or AppExchange packaging. See the Apex testing documentation at https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_code_coverage_intro.htm. This sample test uses HttpCalloutMock so the test does not call the external system.

@IsTest
private class CrmSecurityIncidentJobTest {
    private class SiemMock implements HttpCalloutMock {
        public HttpResponse respond(HttpRequest req) {
            System.assertEquals('POST', req.getMethod());
            System.assertEquals(true, req.getEndpoint().contains('callout:Security_SIEM'));

            HttpResponse res = new HttpResponse();
            res.setStatusCode(202);
            res.setBody('{"accepted":true}');
            return res;
        }
    }

    @IsTest
    static void sendsIncidentPayload() {
        Test.setMock(HttpCalloutMock.class, new SiemMock());

        Test.startTest();
        System.enqueueJob(new CrmSecurityIncidentJob(
            'WD-CRM-REVIEW-001',
            new List<String>{ 'Reviewed connected apps', 'Revoked unknown OAuth sessions' }
        ));
        Test.stopTest();
    }
}

What logs should you review after a Workday data breach style incident?

After a Workday data breach style incident, review identity, app, and data-access signals together. One log rarely tells the whole story.

If your org uses Event Monitoring, align its review with your incident response process. For a related SalesforceTutorial topic, read Salesforce Event Monitoring basics. To check platform availability or official incident posts, use our Salesforce status guide alongside Salesforce Trust.

Common errors with Workday data breach response

Assuming every CRM incident is a Salesforce vulnerability

A Workday data breach discussion can quickly become imprecise. A CRM data incident can come from stolen credentials, social engineering, an approved OAuth app, a vendor integration, weak help desk verification, or mis-scoped permissions. Do not describe it as a Salesforce platform vulnerability unless Salesforce or forensic evidence supports that conclusion.

Resetting passwords but leaving OAuth grants active

OAuth access can remain the real issue. Review and revoke suspicious app sessions. Then rotate credentials, disable integration users, or change policies based on the evidence.

Focusing only on system administrators

A user with broad report export rights or access to high-value Contact fields can create exposure without being a Salesforce admin. Review effective permissions, not job titles.

Skipping the business contact data risk

Business contact data can still support targeted scams. Attackers can combine names, titles, phone numbers, and vendor context to make follow-up messages sound normal.

Best practices for preventing a similar Workday data breach pattern

A Workday data breach prevention plan should be written as a repeatable operating process, not a one-time cleanup.

• Use app approval controls. Users should not be able to authorize unknown OAuth apps without admin review in high-risk orgs.
• Maintain an integration register. Track owner, purpose, data scope, authentication method, token policy, and last review date.
• Apply least privilege to integrations. Create a permission set for the exact objects and fields needed by the integration.
• Separate admin and integration duties. Do not run a vendor integration as a human admin account.
• Train help desk and HR teams. The Workday data breach involved impersonation of HR or IT. Train teams to reject password, token, MFA, and remote-access requests made outside trusted support channels.
• Monitor exports and API volume. Alerts should include unusual report exports, Bulk API usage, and large query activity.
• Practice revocation. Your team should know how to revoke OAuth sessions, disable a connected app, rotate a credential, and preserve evidence before a real incident.

Final checklist for Salesforce admins

Use this Workday data breach checklist after reading any CRM incident notice or vendor security update:

1. Confirm the Workday data breach source: official vendor statement, Salesforce Trust advisory, legal notice, or internal incident report.
2. Identify the involved CRM, connected app, middleware, or integration user.
3. Review Connected Apps OAuth Usage and revoke unknown or risky sessions.
4. Check login history, identity-provider logs, and Event Monitoring data.
5. Validate profiles, permission sets, sharing rules, and field-level security for exposed data types.
6. Rotate credentials only after you understand which tokens or secrets are in scope.
7. Document actions in a ticketing or SIEM system using a tested process, not ad hoc notes.
8. Update training and help desk verification scripts to address phone and text-based impersonation.

Frequently Asked Questions