A compliance manager preparing for an audit can see who logged into Salesforce. What often remains unclear is what that user did later in the same session. The same session may approve a risky change or advance a deployment without anyone confirming the user's identity again. DevOps engineers face the same problem during releases.

Salesforce environments in regulated industries expose this gap. Multi-factor authentication verifies identity at login. The session then runs on static trust until timeout, even as user context and risk levels shift.

Continuous authentication under Zero Trust requires more than a strong login. Salesforce session controls stop short of that standard, and the gap affects both compliance duties and deployment workflows.

This article identifies where Salesforce session controls miss zero trust requirements, documents the compliance impact, and evaluates controls that close the gap.

Salesforce access design must support continuous verification

A one-time login does not satisfy Zero Trust for Salesforce access. Access decisions must be re-evaluated during the session because trust can change after authentication.

NIST SP 800-207 defines Zero Trust as minimizing uncertainty in least-privilege, per-request access decisions. The framework applies directly to cloud assets outside enterprise-owned network boundaries.

Three tenets matter most for Salesforce environments:

1. Per-session access grants. Access to individual resources is granted on a per-session basis, not through persistent broad permissions from a single login.
2. Dynamic policy enforcement. Access decisions incorporate observable state of client identity, application context, and behavioral and environmental attributes.
3. Continuous verification throughout sessions. Authentication is a constant cycle of access, threat assessment, adaptation, and re-authentication. It includes re-authentication triggers such as time intervals, new resource requests, and resource modifications.

The takeaway is direct. Trust must be validated at the point of access, not only at session start. A single authentication event should not grant extended, unmonitored resource access (NIST SP 800-207).

Salesforce session controls leave a zero trust gap

Salesforce authenticates strongly at login. It does not natively apply continuous verification throughout the rest of the session.

Salesforce enforces MFA at login. After successful authentication, the platform creates a session identifier to preserve session state. That session carries trust until timeout.

The gap appears after login. Salesforce does not natively re-authenticate users when behavior changes during an active session, nor does it re-evaluate trust based on geographic shifts or elevated-risk actions.

The platform's own encryption documentation sets a clear boundary. Shield Platform Encryption is not appropriate for stopping account takeover caused by social engineering or malware. Event Monitoring with Transaction Security Policies offers the closest native capability: it can automatically end sessions in near real time when high‑risk or anomalous behavior is detected. However, session termination is not the same as continuous authentication. Event Monitoring reacts to predefined anomaly rules rather than re-verifying identity. It ends sessions rather than requiring step-up re-authentication. It does not dynamically re-evaluate trust based on changing user context the way NIST SP 800-207 envisions continuous verification.

Session security levels classify SSO configurations as Standard or High Assurance. Those labels are static classifications. They are not dynamic risk evaluations.

The same issue affects deployment workflows. Pipeline guidance treats each deployment stage as its own trust boundary, but Salesforce does not natively validate identity at each stage.

What unauthorized access looks like without continuous verification

The session gap is not a theoretical concern. It maps directly to attack patterns that target Salesforce environments.

Consider session hijacking. An attacker who intercepts a valid session token after login inherits the full trust level of the original user. Without continuous verification, there is no mechanism to detect that the person behind the session has changed. The attacker can export records, modify configurations, or escalate permissions without triggering re-authentication. Salesforce's static session model treats every action within the session as equally trusted, regardless of how the behavior compares to the user's established patterns.

Credential compromise creates a similar exposure. Social engineering and phishing campaigns regularly target Salesforce credentials. Once an attacker passes the initial MFA challenge, they operate inside the session with the same access the legitimate user holds. If the user has access to sensitive Salesforce data — customer records, financial information, protected health information — the attacker does too. No additional identity check stands between the compromised login and the data.

Insider threats also exploit the gap. An employee who authenticates legitimately at the start of a shift can perform actions later in the session that exceed their normal scope. Without mid-session verification, bulk data exports, permission changes, or metadata modifications proceed unchallenged. The activity may not surface until a post-incident audit review, long after the damage is done.

Each of these scenarios shows the same structural weakness. Login-time authentication confirms identity once. Continuous authentication confirms identity throughout the session, at the moment each action occurs. The difference determines whether unauthorized access is blocked or merely logged after the fact.

The session gap creates direct compliance exposure

Continuous authentication may not appear by name in every regulation. The underlying duties still require identity verification, activity review, and record retention. Organizations that embed compliance into their DevOps processes rather than treating it as a final checkpoint are better positioned to address these requirements systematically.

HIPAA technical safeguards

HIPAA requires identity verification for systems that handle ePHI. 45 CFR § 164.312(d) requires procedures to verify that a person seeking access to electronic protected health information is the one claimed.

The verification requirement does not specify a single checkpoint. In practice, a Salesforce session that accesses ePHI records over a multi-hour period without re-verification leaves the organization unable to confirm that the same person was behind every access event. If an auditor asks whether the user who logged in at 9:00 AM is the same person who exported 10,000 patient records at 2:00 PM, the static session model provides no evidence beyond the original login event.

HIPAA also requires audit review. 45 CFR § 164.312(b) requires mechanisms to record and examine activity in systems that contain ePHI. The activity review standard under 45 CFR § 164.308(a)(1)(ii)(D) requires regular review of audit logs and access reports. Documentation must be retained for six years.

Without continuous verification events logged during the session, the audit trail only confirms who logged in and what actions were performed. It does not confirm that the authenticated identity was still valid at the time of each action. That distinction matters during breach investigations and OCR audits.

GDPR access control obligations

GDPR requires access controls that support data protection by design. Article 32 requires measures appropriate to the risk, including controls that help preserve confidentiality and security of processing. Article 25 requires technical measures that enforce data-protection principles effectively.

For Salesforce environments that process EU personal data, these requirements translate into a practical obligation: access controls must reflect the sensitivity of the data being processed, not just the identity of the person who started the session. A user who logged in to update account addresses should not retain the same level of trust when they later access financial records or export personal data in bulk. Without continuous verification, the access control posture remains static while the risk level of the user's actions changes.

GDPR does not prescribe a fixed audit log retention period. It requires a purpose-based determination instead. That matters for Salesforce because retention settings must align with the organization's legal and operational basis for keeping records. Organizations must be able to demonstrate that their access control and logging measures were appropriate to the processing risk at the time data was accessed — not just at the time the session began.

SOX internal controls

SOX turns the same gap into an internal control issue for financial reporting systems and release processes. Section 404(a) requires management to assess the effectiveness of internal control over financial reporting. SEC guidance leaves the technical implementation to management's risk assessment.

The deployment dimension is especially relevant for SOX. When Salesforce metadata changes affect financial reporting processes — such as validation rules on opportunity amounts, approval workflows for revenue recognition, or Apex triggers that calculate commissions — the release itself becomes an internal control event. If the developer who committed the code is the same person who deployed it to production, without re-verification at the deployment stage, the organization cannot demonstrate effective segregation of duties. Auditors evaluating IT general controls will look for evidence that the person who made the change is not the same person who approved and executed the release.

Record retention creates a second issue. SEC rules establish a seven-year retention period for certain audit documentation. Salesforce's native Setup Audit Trail retains data for 180 days. That does not align with a seven-year documentation window. Organizations that rely on native logging alone will find themselves unable to produce deployment and access records when auditors request them years after the fact.

Zero trust must extend into deployment pipelines

The compliance exposures above share a common thread: each regulation requires identity assurance and audit evidence that Salesforce's static session model does not produce on its own. That gap is especially acute in deployment pipelines, where a single release can touch financial reporting logic, personal data processing, or ePHI systems.

Deployment pipelines carry the same risk as user sessions. A developer who authenticates once at the start of a release cycle can push metadata to production hours later without re-verification. If that developer's credentials were compromised between login and deployment, or if a different person gained access to the workstation, the pipeline executes the deployment under the original identity. The audit trail records the authenticated user, not the person who actually initiated the change.

Each release stage should act as a separate access decision with its own verification and policy checks. In CI/CD pipelines, users, build services, and automation accounts are not inherently trusted. Each stage functions as an independent trust boundary.

Identity verification at each stage

A single authentication event at pipeline start leaves later stages operating on inherited trust (NIST SP 800-204D). That model breaks zero trust. Each stage carries a different risk level and needs separate credential validation.

Effective continuous verification in deployment workflows requires four checkpoints:

• Code commit: Verify developer identity and check proposed metadata against security policy before merge. The commit stage establishes the first link in the chain of accountability. If a developer's credentials were compromised after login, a re-verification step at commit time catches the discrepancy before unauthorized code enters the repository.
• Build: Authenticate the service account and sign artifacts to create an immutable chain of custody. Build-stage authentication should use certificate-based methods rather than stored credentials. This prevents long-lived tokens from becoming attack vectors and ensures each build session is independently verified.
• Test: Run validation in a separate environment that uses distinct credentials. Testing environments should enforce their own access controls so that a compromised development credential cannot be reused to bypass test-stage gates.
• Deployment authorization: Require explicit release permissions that remain separate from developer access. The person who wrote the code should not be the same person who authorizes its promotion to production.

Salesforce DevOps Center supports part of this model through distinct permission sets. An engineer cannot deploy metadata to production without explicit release manager permissions, even with an authenticated development session.

However, DevOps Center does not enforce re-authentication at each stage or integrate directly with enterprise MFA providers for step-up verification during deployment. Flosum closes this gap by operating natively within Salesforce and extending the platform's MFA and session framework across the full deployment lifecycle — from commit through production release.

Policy-based deployment gates

Deployment gates should enforce policy automatically because manual review alone does not satisfy zero trust. Automated policy enforcement should span application development and deployment.

In Salesforce, that means placing a different control at each gate. Pre-deployment scans check code and configuration risk. Compliance gates confirm approvals. Impact analysis evaluates what the release touches. A security-first pipeline framework integrates these controls into a unified workflow rather than treating them as isolated checkpoints.

Flosum operationalizes these gates within its native Salesforce pipeline. Each deployment step can enforce approval workflows that require separate reviewers for code changes and production deployments. Pre-deployment validation scans metadata for conflicts and security issues before changes reach production. Every action in the pipeline — who initiated it, who approved it, what changed, and when — is recorded in an immutable audit trail.

Closing the continuous authentication gap

Regulated Salesforce environments need stronger controls in both the user session layer and the deployment layer. Closing the gap requires identity checks during sessions and policy enforcement across releases.

Strengthening the user session layer

At the identity layer, organizations should configure Salesforce as a SAML 2.0 service provider with High Assurance session classification. They should enforce conditional access policies through enterprise identity providers that evaluate device compliance, user risk scores, and behavioral signals before granting or continuing access. This reduces risk in the user session layer by ensuring that trust decisions reflect current context rather than login-time conditions alone.

Organizations should also configure Transaction Security Policies to require step-up MFA for sensitive operations. For example, a policy can trigger re-authentication when a user attempts a bulk data export, accesses a restricted object for the first time in a session, or performs an action from an unrecognized IP address. These policies bring continuous verification closer to the NIST standard within Salesforce's native capabilities.

Closing the deployment layer gap

At the deployment layer, purpose-built Salesforce DevSecOps tools address controls that identity providers alone do not cover. Identity providers secure the session. Deployment tools must secure the pipeline.

Flosum integrates with Salesforce's MFA to enable continuous authentication at every deployment stage. Because it is built natively on the Salesforce platform, Flosum leverages the same authentication infrastructure — including MFA challenges, session policies, and permission sets — to validate identity at each step of the deployment process. A developer who commits code is re-verified before that code can be merged, built, tested, and promoted. A release manager must authenticate separately to authorize production deployment. No single authentication event carries trust across multiple pipeline stages.

This architecture directly addresses the compliance exposures identified earlier in this article:

• HIPAA: Per-stage identity verification produces a documented chain of custody that auditors can trace from commit through production, with timestamps and verified identities at each checkpoint.
• GDPR: Policy-based deployment gates generate the evidence required to demonstrate appropriate technical measures under Articles 25 and 32, with access checks proportionate to data protection risk.
• SOX: Independent verification of developers, reviewers, and release managers at each pipeline stage satisfies IT general control requirements for change management and produces deployment records that persist beyond the native retention window.

Flosum also provides automated deployment pipelines for Salesforce metadata, supports policy-based deployment controls, generates audit trails for compliance reporting, and enables version control and CI/CD workflows with rollback capabilities within Salesforce environments. Audit trail data persists beyond the 180-day native retention limit, supporting seven-year SOX retention requirements and six-year HIPAA documentation obligations.

Complete deployment history and change documentation strengthen audit readiness. Request a demo with Flosum to explore how continuous authentication enforcement and audit trail automation address your compliance requirements.