Yes. Packages, low-code extensions, and connected apps can all expand who or what can reach sensitive data, so the security boundary is no longer the core tenant alone. If a package can change storage, permissions, or data flow, it belongs in the same governance review as any other access pathway.
Why third-party Salesforce packages belong inside the identity perimeter
Salesforce packages are not just code add-ons. They can introduce new data paths, permission models, automation, and external connections that act on behalf of users or the tenant itself. If a package can read, write, sync, or transform records, it can widen access in ways that are functionally similar to adding another trusted identity pathway.
That is why teams should review packages as governed access surface, not as harmless feature extensions. A package may be installed by an admin, but its ongoing privileges, connected app relationships, and data handling behavior determine whether it can reach sensitive objects, export data, or alter controls after deployment.
Packages that integrate through OAuth, external APIs, or synchronised workflows should be treated as part of the same trust chain as other third-party access paths. For examples of how token-based integrations can expand Salesforce exposure, see Salesloft OAuth token breach, Klue OAuth Supply Chain Breach, and Ultimate Guide to NHIs, what are non-human identities.
What changes when a package can touch data, permissions, or flows
The main change is blast radius. A package that can only display data is different from one that can modify records, create users, change sharing rules, or invoke downstream systems. Once those abilities exist, the package can become an indirect control point for confidentiality, integrity, and availability, even if the package vendor never receives direct tenant credentials.
This is also where low-code risk becomes operational rather than theoretical. Declarative logic, installed components, and marketplace apps may bypass the design assumptions of the core CRM team. A package can create shadow data paths, duplicate data into external services, or trigger actions that security teams do not review with the same rigor as custom code.
The governance question is therefore not only “who installed it?” but “what authority does it retain after installation?” That includes object-level access, field visibility, background jobs, event subscriptions, and any connected app or integration secret that can outlive the original approval decision.
For broader identity governance and access review concepts that help structure this review, see IAM and IGA Basics, NHI Lifecycle Management Guide, and Third-Party, B2B and Contractor Access Guide.
What a mature review should check before a package is trusted
A useful review starts with effective permissions, not marketing descriptions. Teams should verify which objects, fields, records, exports, callbacks, and automation hooks the package can actually use, then compare that to the minimum business need. If the package relies on a connected app or token, that credential path needs the same ownership, expiry, and revocation discipline as any other privileged integration.
The second check is control of change. Packages can be updated after approval, and vendor-side changes may silently alter behavior, permissions, or data handling. A package that was acceptable at install time may become risky later if its scope expands or its dependencies change.
The third check is evidence. Teams should be able to show who approved the package, what access it requested, what data it touched, and how it is monitored or removed. If that evidence cannot be produced quickly, the package is probably sitting outside the organisation’s real identity perimeter even if it is formally “installed.”
Useful reference points for those checks include OWASP Non-Human Identity Top 10, NIST SP 800-53 Rev 5 Security and Privacy Controls, and OpenID Connect Core 1.0.
Risk and Threat Considerations
Third-party packages create risk because they combine delegated trust with persistent access. If a vendor, package maintainer, or connected app is compromised, attackers may inherit the package’s access path into Salesforce data and workflows without needing to break the core tenant directly.
Failure mechanism: The package is approved once, then accumulates hidden reach through tokens, permissions, or workflow integrations that are not re-reviewed when the package changes or when vendor credentials are stolen.
Impact: Sensitive CRM data can be exposed, altered, or exfiltrated at scale, and the package may also become a pivot point into adjacent systems that trust Salesforce events or exports.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party packages and connected apps can expose trust-chain compromise. |
| Recommendation — Review third-party package trust paths and restrict vendor-issued access to the minimum scope. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Packages often depend on tokens and secrets that require lifecycle control. |
| AC-6 — Least Privilege | Package permissions should be constrained to the minimum needed to function. | |
| CM-8 — System Component Inventory | Packages and connected apps need inventory and ownership for governance. | |
| Recommendation — Manage integration secrets with expiry, rotation, and revocation controls. Limit installed package privileges and remove any excess object or field access. Maintain an inventory of installed packages, connected apps, and their owners. | ||
Practitioner Guidance
What to prioritise: Treat packages with data write access, admin-like permissions, or outbound integrations as high-risk by default. Those are the cases where the package’s effective authority matters more than whether it arrived through an approved marketplace.
What to verify: Confirm the package’s actual object and field reach, the connected app or token it uses, and whether uninstalling the package fully removes its access path. If revocation depends on a vendor action you do not control, the governance case is weaker than it first appears.
Common mistake: Teams often review installation approval but not post-installation authority. That gap is where packages quietly turn into standing access paths, especially when they are left in place after the original business need has passed.
Practitioner takeaway: If a third-party Salesforce package can alter data flow, permissions, or privileged automation, review it like any other delegated identity or access pathway, not like a simple app plugin.