If you haven’t audited your org yet, here’s exactly how to do it.

What counts as phishing-resistant?

Salesforce tracks two phishing-resistant methods:

• HasSecurityKey = true — a registered WebAuthn security key. This includes hardware keys (YubiKey, etc.) as well as synced passkeys from iCloud Keychain, 1Password, or Bitwarden, as long as the manager is FIDO2/WebAuthn-compliant.
• HasBuiltInAuthenticator = true — a registered platform authenticator (Windows Hello, Touch ID, or Face ID bound to that device).

Standard MFA methods — HasSalesforceAuthenticator and HasTotp — do not satisfy the phishing-resistant requirement and will trigger a step-up prompt at login after the enforcement date.

Step 1: Create the “MFA API Access” permission set

The TwoFactorMethodsInfo object requires elevated permissions to query. Create a permission set that grants them.

1. Go to Setup → Permission Sets → New
2. Name it MFA API Access, leave the license blank
3. Open System Permissions
4. Enable Manage MFA in API and Manage MFA in User Interface
5. Save, then assign the permission set to your user via Manage Assignments

Without this, the SOQL query below will return a INSUFFICIENT_ACCESS error.

Step 2: Run the audit query

Open the Developer Console or use Workbench and run:

SELECT User.Username, User.Profile.Name,
       HasBuiltInAuthenticator, HasSecurityKey, HasU2F,
       HasSalesforceAuthenticator, HasTotp
FROM TwoFactorMethodsInfo
WHERE User.IsActive = true

This gives you a row per active user who has registered at least one verification method, showing exactly which factors each person has in place.

Step 3: Find who isn’t ready

Narrow the results to users who have no phishing-resistant method registered:

SELECT User.Username, User.Profile.Name,
       HasBuiltInAuthenticator, HasSecurityKey, HasU2F,
       HasSalesforceAuthenticator, HasTotp
FROM TwoFactorMethodsInfo
WHERE User.IsActive = true
  AND HasBuiltInAuthenticator = false
  AND HasSecurityKey = false

Anyone returned here would hit the step-up wall after July enforcement. Tighten the scope to the highest-risk profiles:

SELECT User.Username, User.Profile.Name,
       HasBuiltInAuthenticator, HasSecurityKey, HasU2F,
       HasSalesforceAuthenticator, HasTotp
FROM TwoFactorMethodsInfo
WHERE User.IsActive = true
  AND HasBuiltInAuthenticator = false
  AND HasSecurityKey = false
  AND User.Profile.Name = 'System Administrator'

To focus on admins specifically, cross-reference the results against a User query filtered by Profile.Name = 'System Administrator'. Do the same for any profiles or permission sets granting Modify All Data or Manage Users — those users carry the same risk as sysadmins.

Two caveats you need to know

Users with zero methods won’t appear. A row only exists in TwoFactorMethodsInfo once a user has registered something. Users who have never set up any MFA at all are silently absent. Cross-check your query results against a full active-admin list (SELECT Username FROM User WHERE IsActive = true AND Profile.Name = 'System Administrator') to catch anyone missing entirely.

Legacy U2F is a gray area. HasU2F (flagging keys registered under the old FIDO U2F protocol) is tracked separately from HasSecurityKey (WebAuthn). If anyone has a legacy U2F registration, it’s safer to have them re-register under WebAuthn rather than assume Salesforce will honor it toward the phishing-resistant requirement. Hardware keys like YubiKeys support both; the re-registration takes about a minute.

What to do with the results

Once you have your at-risk list:

1. Choose a method for each user. Platform authenticators (Windows Hello, Touch ID) are zero-cost and built into devices most admins already use. Hardware keys are the better fit for shared workstations or users who move between machines.
2. Have users register before the deadline. Walk them through Setup → Advanced User Details → Register under the Security Key or Built-In Authenticator section.
3. Re-run the audit query after registration to confirm HasSecurityKey or HasBuiltInAuthenticator flipped to true.
4. Don’t forget service/API users. Automated integrations authenticating as admin users need certificate-based or OAuth flows that don’t require interactive MFA — make sure those are in place before enforcement hits.

The query takes two minutes to run. The harder part is the follow-up with users who’ve been putting off the upgrade. Give them a specific deadline a week before Salesforce’s, so you have buffer to resolve stragglers before the forced step-up affects production access.

However, the restriction can be overcome through strategic permission configuration. The process involves five steps:

Step 1: Create Permission Set

Establish a new permission set titled “Integration Permission Set” with no assigned license.

Step 2: Create Integration User

Set up a dedicated user with the “Salesforce Integration” license and assign the “Salesforce API Only System Integration” profile.

Step 3: Assign Permission Set License

This represents the critical phase. The Salesforce API license defaults to severe restrictions. Navigate to “Permission Set License Assignments” and enable the “Salesforce API Integration” license—this restores standard functionality.

Step 4: Enable Run Flows Permission

Access the Integration Permission Set’s App Permissions section and activate the “Run Flows” checkbox.

Step 5: Assign Permission Set to User

Complete the configuration by assigning your newly created permission set to the integration user through the Manage Assignments button.

Note: Without enabling the permission set license in Step 3, attempting to assign the permission set generates an error message regarding incompatible user licenses.

There are two key identifier types: the Alias identifier (a random GUID assigned at contact creation) and the xDB.Tracker (assigned only during web visits). The problem occurs when merging contacts—the system fails to preserve the xDB.Tracker, leaving contacts unable to process subsequent web visits.

When affected, users encounter an error stating “Contact…must have a tracker identifier.” This breaks tracking functionality until users clear their cookies, forcing them to essentially restart their session.

The Solution

The solution involves creating a custom pipeline processor that executes before Sitecore’s standard conversion process. This processor checks for missing xDB.Tracker identifiers and regenerates them via xConnect API calls when necessary. This fix resolves approximately 60 daily errors down to roughly one occurrence every 4-5 days.

This approach is a temporary workaround—hopefully the community can help reproduce the underlying issue for official Sitecore resolution.

Expected Errors in Sitecore Logs

The system generates a message stating “ERROR General error when submitting contact. Exception: Sitecore.XConnect.Operations.FacetOperationException Message: Operation #0, AlreadyExists, , Classification Source: Sitecore.Xdb.Common.Web"

Expected Errors in xConnect Logs

Similar FacetOperationException errors appear, indicating batch execution problems with contact classification operations.

Official Solution

A patch exists in the Sitecore Knowledge Base addressing this contact-saving issue.

Persistent Problem in Multi-Server Environments

Even with the patch installed, errors continue in specific configurations:

• Multiple Content Delivery servers
• Load balancer implementation
• Session state stored in-process (not Redis, MongoDB, or SQL)

Root Cause

When clients switch between servers or devices, in-process sessions disconnect, severing the contact reference. New sessions attempting to save contacts generate duplicate operation errors.

Resolution

Move both shared and private session state to Redis, SQL Server, or MongoDB using Sitecore’s official configuration walkthroughs.

Note: SQL implementations won’t function in Azure SQL due to temp database requirements.

Contact Section

The contact tab houses all xConnect-related contact data, including:

Identifiers - A comprehensive list of assigned identifiers and merged accounts, containing source, identifier value, type, and validity status.

IsKnown - Indicates whether a contact has been identified using methods beyond Sitecore’s default identifiers, such as through the IdentifyAs() function or direct xConnect assignment.

ExpandOptions - Displays available facets for xConnect interaction, functioning as a registry of known facets.

ConcurrencyToken - A GUID that Sitecore applies to all facets. Mismatched tokens during save operations trigger an error, preventing facet overwrites. Each object possesses a unique token.

LastModified - Timestamp of the most recent contact modification.

Id - The primary contact identifier visible in Experience Profile URLs and the Contacts table within shard databases (distinct from tracker contact IDs).

Visit Data Section

Current interaction information specific to the active web visit:

• BrowserInfo - Browser identification data including major name, minor name, and version.
• ChannelId - Current visit’s assigned channel, variable based on traffic source.
• DeviceId - Associated device identifier from Sitecore’s device registry.
• GeoData - Geographic information derived from IP geolocation services (available free in Sitecore 9.x).
• HasGeoIpData - Boolean indicating geolocation data availability.
• InteractionId - Unique identifier for the specific web visit.
• Ip - User’s IP address in hexadecimal format (requiring hex decoding).
• Keywords - Keywords assigned to the interaction.
• Language - Current visit’s language designation.
• ScreenInfo - Device screen dimensions as Sitecore perceives them, based on browser-provided data.
• SiteName - Identified Sitecore site from the sites configuration node.

Pages Section

Comprehensive listing of all pages visited during the current interaction, excluding pages from previous sessions. Contains page title, URL, and blank-window status.

Goals Section

Records goals triggered during web visits or out-of-channel activities, displaying engagement value, title, UTC timestamp, current/past visit designation, and associated event data.

CurrentGoals - Goals triggered within the current session, enabling Sitecore to personalize based on present-session activity.

PastGoals - Goals triggered before the current visit, allowing personalization based on historical behavior. Current session goals transition to past goals upon visit closure.

Facets Section

Lists all available contact facets populated from ExpandOptions. Example Personal facet contains birthdate, name components, gender, job title, language preference, concurrency token, and modification timestamp.

Profiles Section

Tracks current and historical pattern card assignments based on profile scoring:

CurrentProfiles - Active pattern cards with profile name, score, count, and pattern details.

PastProfiles - Historical pattern cards with scoring frequency, totals, and individual score records by key-value pairs.

Key Features

The tool displays:

• xConnect Details
• Facets
• Goals
• Marketing Plans
• Campaigns
• History
• Patterns and profiles

Background

The project originated in 2017 when James Williamson requested a way to identify a user’s profile during an active session without terminating it. The initial solution used a simple API endpoint (/apis/v1/visitordetails) that returned xConnect profile data in JSON format.

Evolution to xDB Peek

The upgrade transforms this functionality into a user-friendly interface accessible without browser extensions. Instead of viewing raw JSON strings, data now organizes into distinct tabs for clarity. The tool supports both desktop and mobile viewing, recognizing that personalization experiences differ across devices.

Future Development

The team plans to expand beyond read-only capabilities, adding functions such as triggering goals, enrolling users in pattern cards, merging contacts, and executing other operational tasks.

The release targets Sitecore 9.x versions and is available on GitHub at the Bonfire repository.

The implementation involves three main steps:

Step 1: Add the NuGet Package

Install the EPExpressTab NuGet package to begin development.

Step 2: Create a Model and View Model

Build a model to hold your facets and other necessary data. Then construct a view model extending the EpExpressViewModel class, which specifies the CSHTML view location for the EP tab.

Step 3: Design the CSHTML View

Create the presentation layer injecting into the new EP tab. I incorporated Sitecore’s styling to maintain visual consistency with Speak.

How It Works

EP Express Tab automatically detects classes inheriting EpExpressViewModel and generates corresponding tabs in the core database. The tab naming derives from the TabLabel property, and the rendering automatically integrates into Experience Profile’s presentation details.

For multiple tabs, developers simply create additional view models and views. The tab ordering can be adjusted within the core database at /sitecore/client/Applications/ExperienceProfile/Contact/PageSettings/Tabs/.

I needed to find a contact ID using a known email address. In the previous version, a simple Mongo query would retrieve this information. However, in 9.x, the identifiers are encoded in hexadecimal format.

Using an online hex-to-ASCII converter, I confirmed these are standard hex characters without encryption. Here are two SQL queries to work with this data:

Query 1: Display All Email Identifiers

This query displays all email address identifiers in readable format using a CONVERT function to decode the hexadecimal values.

SELECT CONVERT(VARCHAR(100), Identifier) as Email
FROM [xdb_collection].[ContactIdentifiers]
WHERE Source = 'email'

Query 2: Find Specific Email

This query finds a specific email address by converting the search term to VARBINARY format and comparing it against the stored Identifier column.

SELECT *
FROM [xdb_collection].[ContactIdentifiers]
WHERE Identifier = CONVERT(VARBINARY(100), 'user@example.com')

This approach allows direct database access to retrieve contact information from the xConnect shard databases.

In Sitecore 8.2 Update 6 and 7, as well as 9.1 Update 1, the kernel contains a bug that crashes when encountering bad internal links. This malfunction can either crash the Rebuild Link Database application or bring down an entire site. When Sitecore attempts to resolve a link without proper error handling, it can fail deep within kernel code, producing a “System.FormatException: Unrecognized Guid format” error.

The Patching Challenge

The solution involves a Sitecore knowledge base patch that completely replaces the Sitecore.Kernel dll. However, this presents a patching challenge: Sitecore does not publish hotfixes through NuGet packages; they release fixes through their knowledge base for selective implementation.

Two Approaches

1. Include the patched kernel in builds
2. Exclude it entirely and patch servers manually

I advocate for the first option, emphasizing intentional CI builds that eliminate snowflake servers—environments with undocumented, manual patches.

Recommended Solution

Create an Infrastructure.Patch project within Helix solutions to manage all patches centrally. This approach ensures consistency across environments and simplifies upgrades. By incorporating patches directly into build processes, organizations can achieve their goal of rebuilding production environments entirely through CI scripting.

I originally created a JSON application for version 8.2 and have maintained it through the 9.1 release cycle.

Key Feature: Handling Sitecore Facets

The system retrieves requested facets through ContactExpandOptions. My approach involves accessing the xConnect server configuration to obtain all KnownModels (available facet models), passing these into ContactExpandOptions to retrieve and serialize all facets.

JSON Output Includes

The resulting JSON output includes:

• Identifiers
• Contact status
• Visited pages
• Interaction details
• Current and past goals
• Current and past events
• xConnect facets with values
• Current profile identification
• Past profile identification

Check the GitHub releases page for access to the tool.