You can automate Salesforce MFA login with passkeys in Leapwork Play by creating a reusable Login test that completes any required TOTP verification, detects the Salesforce passkey/WebAuthn prompt, captures the passkey, and reuses the authenticated login across Play tests, RunLists, and CI executions. This allows privileged-user tests to follow the approved phishing-resistant MFA journey without requiring an MFA exemption.
TOTP has been one of the most practical ways to automate MFA in unattended UI tests. It is still supported, but it is not phishing-resistant, and security policies are increasingly moving higher-risk authentication toward passkeys and other phishing-resistant methods.
Salesforce is one very visible example of that transition. Leapwork Play gives QA teams a way to automate both the existing TOTP journey and the emerging passkey/WebAuthn journey.
Salesforce began enforcing phishing-resistant MFA for privileged users in July 2026, with the rollout continuing by release group. For System Administrators and users with permissions such as Author Apex, Customize Application, Modify All Data, or View All Data, TOTP is no longer a phishing-resistant authentication method. Salesforce supports WebAuthn passkeys and security keys for these privileged-user logins.
For QA teams, the problem is simple. An unattended Salesforce UI test still has to get through the same login journey. You can seek an exception for some automation accounts, but then the test follows a different authentication path and weakens the security controls. If you want to validate the real privileged-user path, the automation has to complete the passkey challenge.
Beyond Salesforce
Salesforce is the example in this guide, but the same Play approach can be used with other applications and identity providers that support passkeys or WebAuthn. The exact authentication journey depends on the provider and its security policy, but the pattern stays the same: automate the approved passkey-protected login once and reuse it across your tests.
Security boundary
Play does not bypass Salesforce MFA, your identity provider, Conditional Access, permissions, passkey governance, or credential controls. Those controls still apply. The point is to automate the same security path instead of using workarounds and compromising security.
See the passkey login run in Play
This demo shows the full Salesforce transition: Play detects the TOTP verification page, generates the verification code from a securely stored team secret, detects the required passkey setup, captures and stores the passkey for future automated runs, and reaches the signed-in Salesforce session
Why Salesforce MFA automation is changing
Salesforce now distinguishes between standard MFA and phishing-resistant MFA. TOTP can still be used where standard MFA is accepted, but privileged users are required to use a phishing-resistant method. That changes the options available to unattended UI automation.
During passkey enrollment, Salesforce may still ask the user to verify identity using an existing method such as TOTP before the passkey is created.
|
Existing automation approach |
What happens now |
|
Username + password only |
Blocked when Salesforce requires MFA. |
|
Generate a TOTP code |
Useful for standard MFA and it may also be part of identity verification during passkey enrollment, but TOTP itself does not satisfy the phishing-resistant requirement for privileged users. |
|
MFA exemption or weaker test policy |
Automation works, but the test user follows a different security path from the users you are trying to protect. This is not recommended. |
|
TOTP-to-passkey flow in Play |
Play automates TOTP verification when required, detects passkey setup, captures the passkey, and makes the login reusable. |
Why Play?
Play handles more than the end-state passkey login. It can automate an existing TOTP verification step when Salesforce requires it during enrollment, detect the passkey setup, capture the passkey for future automated runs, and keep the Login reusable from Play, RunLists, or CI. Your QA team does not need separate TOTP and passkey handling around every Salesforce test.
How to automate Salesforce passkey login in Play
Keep authentication as one reusable test asset. Your Salesforce business tests start only after that Login test has completed successfully.
1. Use an approved Salesforce test identity
Use a dedicated automation identity governed by the Salesforce MFA policy you actually want to validate. For privileged-user testing, make sure the identity is enrolled in an approved phishing-resistant method.
2. Complete verification and capture the passkey
During passkey enrollment, Salesforce may first ask the test user to verify identity. In the demo, Play detects the TOTP page, generates the verification code from a securely stored team secret, then detects the passkey setup and captures the passkey for future automated runs. Keep both TOTP secret material and passkey credentials governed by your organization’s identity and secret-management policy.
3. Create one reusable Salesforce Login test case
Record the login once and save it as a shared test case, for example LoginSalesforcePasskey.
|
Reusable Login Flow Open Salesforce -> Verify identity with TOTP (if prompted) -> Passkey setup / authentication -> Salesforce Home -> Verify signed in |
4. Reference LoginSalesforcePasskey from the business test
Keep authentication out of the Salesforce scenario itself. The business test can start with the reusable Login and then continue to Accounts, Opportunities, Cases, Setup, or the admin workflow being validated.
|
Business test LoginSalesforcePasskey → Open Opportunity → Edit Stage → Save → Validate |
5. Run it from Play, a RunList, or your CI trigger
When the test runs, it performs the referenced passkey login and then continues with the Salesforce steps in its own short-lived Play execution environment. Parallel tests still need separate users or isolated backend data where Salesforce records could conflict.
|
Try it with your current Salesforce suite Run the same protected Salesforce login in Play and compare how much passkey/authenticator setup, credential plumbing and CI code remains outside the business test. |
|
If Salesforce is moving your privileged test users from TOTP to passkeys, run the same transition in Leapwork Play. Automate the verification step, capture the passkey, keep the Login reusable, and continue testing the approved security path. The same approach can also be applied to other passkey-enabled applications and identity providers, depending on their authentication flow. Try passkey authentication in Leapwork Play |
Why this matters for enterprise QA
The value is not simply “MFA automation.” Play can handle the transition from an existing verification step to the passkey-protected path instead of forcing QA teams to redesign the login or ask for an MFA exception. That matters when QA, security, and audit teams need confidence that automation is following the approved security journey.
Your Salesforce security policy should not have to be weakened just so your automated tests can log in.
Can Playwright automate Salesforce passkeys too?
Playwright 1.61 introduced a virtual WebAuthn authenticator. The difference is ownership. Credential material, authenticator setup, BrowserContext or storage-state wiring, framework conventions, and CI integration remain the team’s responsibility.
Frequently asked questions
Can Leapwork Play automate both Salesforce TOTP and passkey authentication?
Yes. The demo shows Play detecting Salesforce’s TOTP verification page, generating the verification code from a securely stored team secret, then detecting and capturing the required passkey for future automated runs. TOTP can still be used where Salesforce accepts it, but it does not replace the phishing-resistant passkey requirement for privileged users.
How do I move Salesforce test automation from TOTP to passkeys?
Use an approved Salesforce test identity, complete any existing verification Salesforce requires, capture the passkey in Play, and keep the resulting Login as a reusable test case. The business test starts only after the authenticated Salesforce session is established.
Can I automate a Salesforce System Administrator login with a passkey?
Yes, when the org and security policy allow the test identity and passkey setup. The automation should follow the same phishing-resistant requirement as the privileged user.
Does Leapwork Play bypass Salesforce MFA or Conditional Access?
No. Salesforce and the configured identity provider continue to control MFA, passkey policy, Conditional Access and other sign-in requirements.
Is passkey automation in Leapwork Play limited to Salesforce?
No. Salesforce is the example shown here. The same Play approach can be used with other applications and identity providers that support passkeys or WebAuthn, subject to how that provider implements the authentication flow and its security policy.
Can the Salesforce passkey login run unattended from CI?
Yes. Keep the passkey login as a reusable Play test case and invoke the test from Play, a RunList, or your CI trigger.
Does every Salesforce automation account need a passkey?
No. Salesforce’s phishing-resistant requirement applies to privileged users. Non-privileged users can satisfy MFA with standard or phishing-resistant methods, and Salesforce documents specific exclusions for automated testing and RPA UI logins. Passkeys become relevant when the automation identity is privileged or your organization chooses to protect that identity with phishing-resistant MFA.