Configure Multi-Factor Authentication (MFA) for Salesforce Experience Site users. TRIGGER when: user wants to enable MFA on a community, enforce two-factor authentication for portal users, add MFA to a React Experience Site / Web App, configure ForceTwoFactor permission, create MFA permission sets f

Enabling MFA on Experience Sites Enable Multi Factor Authentication for Experience Site (Community) users by deploying the correct permission sets and verifying the platform handled MFA challenge flow. Scope In scope: Deploying ForceTwoFactor permission set for community users Deploying ApiEnabled permission set (required for post login API calls) Assigning permission sets to community users Troubleshooting MFA not appearing on login Customizing MFA/login page branding via NetworkBranding metadata Out of scope — delegate elsewhere: Building custom login UI → experience ui bundle frontend generate Creating generic permission sets → platform permission set generate Assigning permission sets (if already deployed) → dx org permission set assign Deploying metadata to org → platform metadata deploy Org wide MFA for internal Salesforce users → Setup Identity Verification (not a skill) Prerequisites Before using this skill, ensure the following are already in place: Prerequisite Why Experience Cloud site deployed and active MFA applies to community login — no site means no login flow to protect Community users exist (or will self register) Permission sets are assigned to community users; the site must have a community enabled profile Customer Community or Customer Community Login license enabled Required for community user profiles — without it, user creation and profile deployment will fail Network/Site published at least once The site must be reachable at its URL for login + MFA challenge to appear Note: This skill does NOT handle org setup, license provisioning, or Experience Cloud site creation. If these prerequisites are missing, set them up first via Setup Digital Experiences All Sites New, or deploy your site's base app bundle. Required Inputs Gather before acting: Input How to determine Target org Org alias for sf CLI commands Site name Experience Site (Network) name — resolve via SELECT Id, Name FROM Network (see Step 1); this is the site/Network name, NOT the uiBundles/ app name Community users Which users or profiles to assign MFA to Critical Domain Knowledge These facts are non obvious and frequently cause confusion: Fact Detail No custom UI needed Platform renders the MFA challenge page — no React/LWC component required ForceTwoFactor permission The ONLY way to enforce MFA for community users at login Org Identity Verification checkbox Does NOT enforce MFA for community/portal users — only for internal users vforcesite domain MFA challenge page is always served from the underlying Force.com Site domain — this is expected Always deploy ApiEnabled React Experience Sites make post login REST/Connect API calls ( sdk.graphql , sdk.fetch ); without ApiEnabled they fail with API DISABLED FOR ORG Social Login / SSO is separate from MFA React sites render configured Auth Providers via the built in Social Login component (shipped in 264) — driven by Auth Provider setup, not by the MFA permission sets. See references/social login.md . Login page branding works for React sites Since 264, the NetworkBranding "Login & Registration" section is shown in Setup for Site Containers, so logo/color/footer can be customized in the UI — Metadata API still works too. Workflow Step 1: Resolve the target site (Network) These are React Experience Sites, so both permission sets are always deployed — ForceTwoFactor (enforces MFA) and ApiEnabled (React sites make post login API calls). Resolve the Experience Site's real name and Id from the org — do not assume the uiBundles/ app folder name is the site name. They are frequently different, and the site name must come from the org (the deploy target), not the local project. <site name and <NETWORK ID below come from here: One site → use its Name as <site name and Id as <NETWORK ID . Multiple sites → ask the user which one (show the names). Zero sites → the site isn't deployed yet; stop and tell the user (see Prerequisites). Step 2: Generate permission set files First, detect the project's source directory: Use the result as <source dir (e.g. force app/main/default ) for all commands below. Write both permission sets (React Experience Sites always need both): 1. Read assets/MFA Required For Community.permissionset meta.xml 2. Write it to <source dir /permissionsets/MFA Required For Community.permissionset meta.xml in the user's project 3. Read assets/API Enabled For Community.permissionset meta.xml 4. Write it to <source dir /permissionsets/API Enabled For Community.permissionset meta.xml Step 3: Deploy to org Step 3b: Validate community profile is a network member Before assigning permission sets to users, verify that the community profile is registered as a site member. Without this, community users cannot log in at all (and MFA will never trigger). 1. Query current network members: 2. Check if the community profile is in the list: 3. If the profile is NOT a member , add it to the .network meta.xml : 4. Deploy the updated network metadata: IMPORTANT: If the community profile is not a member of the network, users with that profile CANNOT log in — meaning MFA will never be triggered even if permission sets are correctly assigned. This is a common misconfiguration in freshly deployed orgs. Step 3c: Validate guest profile has Apex class access for login The site login page runs as the guest user (unauthenticated). If the guest profile doesn't have access to login Apex classes, users will get FORBIDDEN: You do not have access to the Apex class named: UIBundleLogin and can never reach the MFA challenge. 1. Find the site guest user profile: 2. Grant access to any missing UIBundle login classes. The six classes are UIBundleLogin , UIBundleAuthUtils , UIBundleForgotPassword , UIBundleChangePassword , UIBundleRegistration , and UIBundleSocialLoginConfig . Run the anonymous Apex in references/setup.md ("Grant Guest Profile Apex Class Access") — it diffs existing access and inserts only what's missing — or deploy <classAccess entries for the same classes to the guest profile metadata XML. IMPORTANT: This is NOT MFA specific, but without it the login page itself is broken. The skill must validate this to ensure MFA can actually be triggered. Common in freshly deployed orgs where the guest profile didn't get full class access. Step 4: Assign permission sets Find community users: If community users exist: Find the permission set IDs: Assign to each user: Alternatively, delegate to dx org permission set assign skill: If no community users found: Ask the user: "No active community users found in this org. Would you like me to create a test community user so you can verify MFA is working?" If user agrees, create a test community user: 1. Find the community profile from the site's network configuration: 2. Create an Account (required as community user parent): 3. Create a Contact (linked to the Account): 4. Create the User with the community profile: 5. Set a password for the test user: 6. Assign both permission sets to the new user: Report the credentials to the user so they can test: "Created test user: mfa.testuser@<site name .test with password: <generated password . You can use these credentials to verify MFA on your site." IMPORTANT: Community users require Account → Contact → User hierarchy. Creating a User without a linked Contact on a community profile will fail. Step 5: Register the permission sets as site members (networkMemberGroups) networkMemberGroups is a membership/access gate — it lists the profiles and permission sets whose holders count as members of the site. It does not assign MFA to users. Assignment happens in Step 4 (per user); register the sets here so assigned users still count as site members. 1. Find the existing .network meta.xml in the project: 2. Read the file and locate the <networkMemberGroups section. 3. Add the permission set entries (if not already present): IMPORTANT: Network metadata deploys are declarative — whatever you deploy becomes the full state. Do NOT create a new .network meta.xml from scratch. Always read the existing file and add entries to it. 4. Deploy the updated network metadata: Step 6: Publish and verify Verification steps: 1. Open incognito browser 2. Navigate to site login page 3. Enter credentials → MFA challenge page should appear (on vforcesite domain) 4. Complete MFA → should land on the site, logged in Rules Rule Rationale Never use the org wide Identity Verification checkbox for community MFA It only affects internal users — has no effect on community login Always deploy ApiEnabled for React sites Post login API calls ( sdk.graphql , sdk.fetch ) will fail without it Permission set names are exact — do not rename MFA Required For Community and API Enabled For Community are the canonical names Do not build custom MFA UI components Platform handles the entire MFA challenge flow — custom UI would duplicate and conflict Always assign before testing Deployment alone does not activate MFA — assignment to specific users is required Gotchas Symptom Cause Fix No MFA challenge on login ForceTwoFactor permission not assigned to user Verify PermissionSetAssignment exists for the user API DISABLED FOR ORG after login Missing ApiEnabled permission Assign API Enabled For Community permission set MFA page shows default Salesforce branding No NetworkBranding metadata deployed Read references/branding.md and deploy custom branding vforcesite in MFA page URL Expected behavior — not a bug Platform serves login/MFA from Force.com Site domain Identity Verification enabled but no community MFA Wrong mechanism used Use ForceTwoFactor via Permission Set instead User already has MFA but isn't challenged Active session exists Test in incognito/private browser Permission set deployed but MFA not enforced Deployed but not assigned Run assignment step — deploy != assign No community users found in org Users haven't been created or self registered yet Offer to create a test community user (Account → Contact → User hierarchy) for verification. Permission sets are still deployed and networkMemberGroups updated — org is MFA ready for when users exist. New users aren't automatically protected by MFA networkMemberGroups only defines site membership — it does not assign permission sets to users Assign MFA Required For Community + API Enabled For Community to each user that needs it (Step 4) FORBIDDEN: You do not have access to the Apex class named: UIBundleLogin Site guest profile missing Apex class access Run Step 3c to grant guest profile access to all UIBundle login classes Community user can't log in (redirects silently or gets portal user email settings error) Community profile not a network member, or email deliverability not set to All Email Add profile to .network meta.xml <networkMemberGroups and redeploy (Step 3b). Verify email deliverability is set to "All Email" in Setup → Email → Deliverability. Output Expectations Files generated in the user's project: File When permissionsets/MFA Required For Community.permissionset meta.xml Always permissionsets/API Enabled For Community.permissionset meta.xml Always When summarizing what was done, do NOT claim that adding permission sets to <networkMemberGroups (or updating the network) causes new or self registered users to automatically get MFA. It does not — networkMemb

experience-ui-bundle-mfa-configure