An audit team asks who approved a production metadata change. The deployment reached production, but the approval trail is incomplete. A DevOps engineer can see the change in Salesforce. They still cannot prove branch-level custody or reconstruct the full deployment path.

Most organizations treat Salesforce security as a platform access problem. They configure permission sets and enable MFA. They assume deployment pipelines inherit the same protections. They do not. A critical gap exists between Salesforce runtime controls and the CI/CD pipelines that push metadata into production. Every unverified deployment creates an ungoverned entry point into regulated environments.

This article provides a structured Zero Trust framework for closing that gap. IT compliance managers get a clear mapping between Zero Trust principles and Salesforce deployment controls. DevOps engineers get pipeline requirements grounded in standards and Salesforce security guidance. Salesforce security programs must treat deployment pipelines as a separate trust boundary.

Where Salesforce Native Controls Fall Short

Salesforce native controls do not secure deployment pipelines. That creates an audit and change-control gap that teams must address outside the runtime layer.

The gaps are not speculative. Salesforce architecture documentation identifies them directly.

Profiles Are Classified as Legacy Architecture

Salesforce's Well-Architected Secure guide instructs organizations to minimize profile usage and migrate access controls to permission sets. Profiles are static. Once assigned, a profile grants a fixed bundle of object permissions, field-level security, and system settings. That bundle does not adapt to session context or risk signals.

Over time, profile management tends to be driven by user complaints rather than top-down security design. This complaint-driven approach leads to an accumulation of standing privileges that directly undermines least privilege enforcement. Permission sets and permission set groups offer a more granular, modular alternative that supports the kind of targeted access governance Zero Trust requires.

The shift from profiles to permission sets is not optional under modern security standards. NIST SP 800-207 Tenet 3 requires that access to enterprise resources is evaluated on a per-session basis. Static profiles cannot satisfy the dynamic, per-connection access evaluation that Zero Trust demands. Profiles grant the same permissions regardless of session context, device posture, or risk level.

Some Permissions Bypass All Sharing Governance

Salesforce's data security model is built on layers. Organization-wide defaults lock data down to the most restrictive level. Role hierarchies, sharing rules, and manual sharing then selectively open access where needed. The "View All" and "Modify All" permissions bypass this entire model for a given object. The org-wide counterparts, "View All Data" and "Modify All Data," go even further. The Platform Sharing Architecture documentation confirms that these permissions ignore the sharing model, role hierarchy, and sharing rules. Standard CRUD permissions respect those controls, sharing-override permissions do not. A single permission assignment can eliminate record-level access controls across the entire organization.

The risk compounds over time. Many administrative actions still require Modify All Data as a generic privilege check for routine tasks, creating a pattern where the permission gets assigned broadly to satisfy functional requirements. Often, the data access Modify All Data grants far exceeds what is needed. Public companies should pay particular attention due to Sarbanes-Oxley compliance. Under NIST SP 800-207, access should be scoped to the minimum necessary and evaluated per session. Permissions that override all sharing governance by design make that standard impossible to meet, creating exactly the kind of standing privilege accumulation that least privilege principles are built to prevent.

API Access Control Is Historically Allowed by Default

Salesforce allows external applications to connect through Connected Apps using OAuth-based API access. By default, Salesforce permits users to access all Connected Applications, even uninstalled ones. Any user with valid credentials could authorize a third-party tool to access organization data without administrator approval.

This default-open posture created real attack vectors. Attackers used social engineering to convince users to authorize data extraction tools via Connected Apps. The OAuth 2.0 Device Flow made exploitation especially easy. Salesforce offers API Access Control to switch an org from "allow by default" to "deny by default." However, API Access Control is opt-in and requires a support case to enable.

Salesforce has begun tightening these defaults. As of September 2025, users can no longer self-authorize uninstalled apps. Salesforce also disabled the ability to create new Connected Apps. The platform is migrating to External Client Apps that enforce a locked-by-default model. Enforcement across all existing orgs began in Spring '26. The tighter defaults are welcome improvements. However, the new restrictions do not retroactively remediate organizations that operated under default-open settings for years without API access control enabled. Until administrators have audited all existing Connected App authorizations, the historical exposure window remains an unresolved risk.

Change Sets Are an Explicit Anti-Pattern

Salesforce's Well-Architected Resilient guide classifies change sets as an anti-pattern. As Salesforce's native deployment tool, the problems with change sets are structural:

• They generate static snapshots that cannot adapt to environmental differences.
• They do not automatically track changes in your org.
• They will not alert you to conflicting changes. If you update an element someone else already changed, you will overwrite their work.
• They lack source control integration entirely. There is no commit history, no diff record, no code review trail, and no rollback mechanism.

If something goes wrong during a change set deployment, there is no straightforward way to revert.

For regulated environments, these limitations are disqualifying. Without version control, organizations cannot produce the evidence of testing, approval chains, or deployment traceability that SOX, HIPAA, and GDPR require. Every change set deployment is an undocumented event from an audit perspective. In a Zero Trust model, an undocumented deployment is an untrusted one.

Deployment Pipeline Security Is Customer Responsibility

Salesforce secures its own infrastructure with rigorous deployment practices. Internally, Hyperforce follows a "never trust, always verify" model. Hyperforce uses just-in-time production access, source-controlled infrastructure artifacts, and immutable container deployments via Kubernetes. Hyperforce also uses safe zero-downtime practices like Blue/Green and Canary deployments.

The catch: none of these controls are available for customer metadata deployments. Signed pipelines, immutable infrastructure, canary releases, and just-in-time access all stop at the platform boundary. When a customer pushes Apex code or custom objects into production, those changes travel through whatever pipeline the customer has built. Or not built.

The shared responsibility model assigns least-privilege implementation, access configuration, and activity auditing to customers. Every organization is responsible for building its own deployment governance. Deployment governance includes identity verification, approval gates, version control, environment segmentation, and audit trail retention. Over-permissive profiles, unmanaged API tokens, and insecure custom code are the gaps most frequently exploited by attackers. The gap between Salesforce's internal deployment rigor and the tools available to customers is precisely where Zero Trust governance must be applied.

The 6 Components of Zero Trust for Salesforce DevOps

A workable Zero Trust model for Salesforce DevOps depends on six controls. Together, the six controls close the deployment gap and create an audit-defensible pipeline model.

Identity-Centric Deployment Verification

Deployment trust must start with identity. Every human and service account involved in deployment must be authenticated for each session.

No deployment action should be authorized based only on network location. NIST SP 800-207 Tenet 3 requires per-connection evaluation. Salesforce supports per-connection evaluation through OAuth JWT Bearer Flow with certificate signing for pipeline service accounts. The API Only profile supports integrations. Separate Connected App credentials per environment support segmentation across organization tiers.

Automated Policy Enforcement Gates

Pipeline controls must enforce release policy before production. Automated enforcement is how compliance requirements become operational controls.

Effective gates include pre-deployment validation using the Metadata API checkOnly flag, automated Apex test coverage thresholds at each pipeline stage, and explicit human approval before production deployment. Automated pipeline success does not constitute production authorization.

Version Control as the Immutable Source of Truth

Version control must hold the authoritative record for every metadata change. Without that record, review, rollback, and deployment traceability break down.

Git-based source control provides the foundation for rollback. Organizations should adopt a version control system to track changes, collaborate, and revert when deployments fail. No direct organization deployments should bypass the Git record. Branch protection rules must restrict production deployments to protected branches with required reviewers.

Environment Segmentation Across Salesforce Organizations

Each pipeline stage should operate as a separate trust zone. That separation limits lateral movement and keeps production controls distinct from lower environments.

Each pipeline stage must operate as a trust zone.

• Developer scratch organizations should be ephemeral and isolated
• Integration sandboxes require separate Connected App credentials
• Staging environments need security policies equivalent to production
• Production organizations require least-privilege apps, human approval, and audit logging

Microsegmentation reduces risk for lateral movement during breaches.

Continuous Monitoring and Immutable Audit Trails

Zero Trust deployment security requires complete records that support accountability. In-organization logs alone do not provide enough evidence for deployment review.

The NIST NCCoE ZTA implementation project identifies SIEM as a foundational function before Zero Trust enhancement. Every deployment event must produce audit-quality logs. Those records should contain:

• the authenticated identity of the deploying service account
• the authenticated identity of the human approver
• branch and commit hash
• target organization
• timestamp
• changed metadata components
• the approval chain

Governance Lifecycle and Compliance Automation

Governance controls must run inside the pipeline. Embedding governance in the pipeline is how teams convert policy into release criteria and retained evidence.

Governance checkpoints must be embedded into CI/CD pipelines, not applied after deployment. Organizations should apply gate controls and audit retention for environments containing regulated data. Security configuration files, including permission sets and Security Center policies, must be version-controlled alongside functional metadata.

Compliance Requirements That Mandate Zero Trust Controls

Regulated Salesforce deployment pipelines require auditable identity, testing, approvals, and retention controls. These overlapping requirements matter because one control model must satisfy several frameworks at once.

This section consolidates those requirements into one reference point.

HIPAA (45 CFR § 164.312)

HIPAA requires unique user identification for every person accessing ePHI. No shared logins are permitted. Audit controls under § 164.312(b) are required with no addressable sub-specifications. Documentation must be retained for six years from creation or last effective date.

GDPR Article 25

GDPR mandates that security controls be embedded in design, not applied retroactively. Article 25(2) requires that personal data is not accessible by default to an indefinite number of persons. That requirement makes least privilege the default posture. Article 32(1) requires regular testing of security measures.

SOX Section 404

SOX requires that configuration changes, metadata deployments, and permission modifications produce evidence of testing. That evidence must be sufficient to support auditor attestation. IT General Controls under PCAOB AS 2201 include logical access, change management, and computer operations controls. Section 802 mandates seven-year audit record retention.

ISO 27001:2022

ISO 27001:2022 matters here because Salesforce states its Hyperforce ISMS is certified to ISO 27001, 27017, and 27018 by an independent third party. That certification provides platform-level assurance context. Customer deployment governance and audit configuration remain customer responsibilities under the shared responsibility model.

For organizations subject to multiple frameworks, the seven-year retention period associated with SOX represents the longest mandatory floor. The SOX retention requirement should govern audit trail configuration.

Bridging the Gap with Purpose-Built DevSecOps

Closing the deployment security gap requires capabilities beyond standard Salesforce controls. Teams need a way to operationalize the framework inside daily release work.

To address those gaps, Flosum provides a purpose-built DevSecOps platform for Salesforce metadata with capabilities that include:

• Automated deployment pipelines with policy-based deployment controls
• Version control and rollback capabilities
• Audit trail generation for compliance reporting
• CI/CD workflow integration within Salesforce environments

These capabilities close the gap between platform security and deployment governance. The result is a deployment model where every metadata change is authenticated, authorized, validated, and logged before reaching production.

When audit deadlines approach, complete deployment history and change documentation reduce preparation time. Request a demo with Flosum to explore how automated audit trails and policy-based deployment controls support your compliance requirements.

FAQ

Why Is Salesforce Runtime Security Not Enough for Zero Trust?

Runtime controls govern user access inside the platform. Deployment pipelines govern how metadata changes reach production. Runtime security and deployment security are separate control planes with different risks.

Why Are Change Sets a Problem in Regulated Environments?

Salesforce classifies active use of change sets as an anti-pattern. Change sets also lack source control integration and a reliable chain of custody for metadata changes.

What Is the Most Important Zero Trust Principle for Salesforce Deployments?

Identity-centric verification is foundational because no deployment action should be trusted implicitly. Every human and service account involved in deployment should be authenticated and authorized for each session.

How Do Compliance Frameworks Affect Pipeline Design?

HIPAA, GDPR, SOX, and ISO-related assurance expectations converge on the same needs. Those needs are unique identity, least privilege, auditable change control, and retained evidence of testing and approvals.

Where Does Flosum Fit in This Model?

Flosum is a purpose-built DevSecOps option for Salesforce environments. Flosum helps operationalize deployment pipelines, policy controls, version control, rollback, audit trails, and governed CI/CD workflows.