Executor User

Expanded Definition

An Executor User is the Salesforce account that executes a registration handler using its own permissions, so the account’s access determines whether federated login can create, update, or complete user actions. In NHI terms, it behaves like a privileged service identity, not a human admin account.

Definitions vary across vendors and implementation guides, but the security meaning is consistent: the executor is the identity that actually performs the backend work after an external assertion or federation event arrives. That makes it distinct from the end user, the identity provider, and any role mapping logic. In practice, the executor’s permissions often become the real control boundary for registration-time access, which is why least privilege and change review matter. This aligns with the risk framing in the NIST Cybersecurity Framework 2.0 and with NHI governance principles discussed in the Ultimate Guide to NHIs.

The most common misapplication is treating the executor as a harmless configuration detail, which occurs when teams over-grant it broad object, profile, or API permissions just to avoid login failures.

Examples and Use Cases

Implementing Executor User controls rigorously often introduces operational friction, because tighter permissions can break onboarding flows or federated registration until the handler logic is tested against real entitlement boundaries.

• A Salesforce Experience Cloud site uses a dedicated executor account to create new users from SSO assertions, but the account is limited to only the objects and fields needed for registration.
• An integration team rotates the executor’s credentials and reviews its profile whenever the registration handler is modified, reducing the chance that hidden privilege creep will widen access.
• Security engineers map the executor to service-account governance in the Ultimate Guide to NHIs and verify that it follows the same review cadence as other privileged NHIs.
• Identity architects test federated login end-to-end using the executor’s actual permissions, rather than assuming the identity provider’s policy is sufficient to authorize downstream actions.
• Platform teams use the executor as a narrowly scoped operational identity, aligning its access model with the least-privilege guidance in the NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

Executor Users matter because they are privileged NHIs that can silently determine whether access is granted, rejected, or mis-provisioned during federation. If the executor is over-permissioned, attackers who abuse the registration path can create accounts, assign unintended access, or trigger workflow actions that bypass intended control points. If it is under-permissioned, legitimate onboarding may fail in ways that look like an application issue rather than an identity control failure.

This is a classic NHI blind spot: the account is often stable, rarely reviewed, and easy to forget after implementation. Yet the broader NHI risk picture shows why these identities cannot be treated casually. NHIMG research reports that only 5.7% of organisations have full visibility into their service accounts, which means executor-style identities can remain hidden long after deployment. The right response is to inventory the account, constrain its permissions, and verify who can change the handler that uses it. Organisations typically encounter the impact only after an unexpected user provisioning event, at which point the Executor User becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern infrastructure identities alongside user identities?
• What is the difference between managing user accounts and managing NHIs?
• What is the difference between service account risk and user account risk in AD?