Issue

Problem Statement

Syensqo currently utilizes SailPoint & IAS for identity management; however, it has been determined that SailPoint does not align with our long-term strategic vision for managing external (B2B) identities. The business

has a rapidly growing footprint of

over 30,000 external identities

(suppliers and B2B customers). While a centralized, purpose-built platform is the long-term target, current project timelines and resource constraints prevent the immediate deployment of a fully-fledged Identity Governance and Administration (IGA) solution. Consequently, Syensqo lacks a scalable, automated solution and must formally adopt a structured, interim approach to handle the lifecycle and authentication of external partners without blocking future technological integration.

Why a Decision is Required

A formal architectural decision is required to select and adopt a new explicitly accept and govern the interim "As-Is" operating model for B2B identity management platform. To future-proof Syensqo's infrastructure, the chosen solution must natively align with our current Microsoft-focused technology stack (specifically Azure). Furthermore, it must possess the out-of-the-box capability to scale seamlessly across our core enterprise SaaS ecosystem, including deep integration with SAP and Salesforce. Adopting this manual, decentralized approach defers capital expenditure and immediate organizational change, but it requires formal acknowledgment of the compounding operational and security risks. Furthermore, this decision establishes the mandate that current manual processes must be standardized and executed in a way that allows for a seamless retrofit into a centralized IGA solution (such as Microsoft Entra or a capable third-party platform) once resources and timelines permit.

Business and Technical Problems Addressed This decision will directly address addresses the following critical gapsimmediate realities:

• Scale Resource and PerformanceTimeline Feasibility: Replaces an unscalable external identity process with a cloud-native solution designed to handle 30,000+ concurrent B2B identities without performance degradation or administrative bottlenecks.

• Lack of Centralization: Resolves the issue of fragmented identity stores by providing a single, unified control plane to govern all external identities and access rights.

• Internal vs. External Segregation: Establishes a clear, secure architectural boundary between internal (employee) identities and external (B2B) identities, fundamentally reducing risk and simplifying compliance.

• Frictionless Integration: Ensures out-of-the-box, standards-based integration (e.g., SAML/OIDC) with Azure, SAP, and Salesforce, eliminating customized point-to-point connections.

Recommendation

Recommendation: Implement Microsoft Entra (specifically utilizing Entra External ID and Entra ID Governance) as the centralized identity governance platform for all external (B2B) identities.

Strategic Rationale

For an organization committed to a Microsoft-first technology strategy, attempting to retrofit a third-party platform like SailPoint for B2B users—or maintaining the current fragmented, manual processes—introduces unnecessary architectural complexity, risk, and operational overhead. Adopting Microsoft Entra as the unified identity control plane is the most secure, logical, and future-proof path to manage our growing scale of 30,000+ external identities.

This recommendation is driven by three core architectural pillars:

1. Ecosystem Consolidation & Native Microsoft Alignment By leveraging Microsoft Entra, the business centralizes its external identity management directly within the Azure fabric it already owns and operates. This minimizes technical debt and eliminates the need for complex, custom-built connectors. Crucially, it allows the organization to govern external partner access using the exact same enterprise security framework—such as Conditional Access and continuous threat monitoring—that currently protects the internal Microsoft 365 and Azure environments.

2. Scalable B2B Segregation Managing an ecosystem of over 30,000 external partners, vendors, and clients requires a purpose-built architecture. Entra External ID establishes a secure, logical boundary between internal employees and external entities, ensuring the core employee directory remains strictly isolated. Furthermore, it shifts a massive operational burden away from internal IT through a Bring Your Own Identity (BYOI) model. This allows external users to securely authenticate using their own organization's credentials, while Entra natively automates the onboarding, access review, and offboarding lifecycles.

3. Frictionless Enterprise SaaS Integration (SAP & Salesforce) While natively embedded in the Microsoft ecosystem, Entra acts as a highly capable, vendor-agnostic identity broker. It features deep, out-of-the-box integrations built specifically for top-tier enterprise platforms like SAP (via SAP Cloud Identity Services) and Salesforce. Entra utilizes open standards like SAML, OIDC, and SCIM to ensure that when an external identity is approved, modified, or terminated in Azure, their access is automatically provisioned or revoked downstream in SAP and Salesforce. This guarantees a single, auditable source of truth across the business.

Background & Context

Syensqo operates within a complex, multi-tenanted enterprise environment with a substantial Microsoft-first cloud strategy anchored in Azure. The organization currently manages over 30,000 external identities—including partners, vendors, contractors, clients, and ecosystem participants—across multiple geographies and business units.

Historically, Syensqo relied on SailPoint Identity Governance as its primary identity and access management (IAM) platform, supplemented by Microsoft Entra ID (formerly Azure AD) for employee identity governance. However, SailPoint was architected primarily for managing internal employee lifecycles and has proven inadequate for the scale, speed, and unique requirements of managing B2B external identities.

The organization's core enterprise applications—SAP ERP, Salesforce, Microsoft 365, and Azure—require seamless, standards-based identity provisioning and access controls. The current point-to-point integration architecture is brittle, difficult to maintain, and fails to provide a unified governance posture across internal and external user bases.

Recent business growth, increased M&A activity, and expanded partner ecosystems have accelerated the external identity footprint beyond SailPoint's operational scalability. This has created an urgent business need to adopt a purpose-built, cloud-native B2B identity solution that can operate at scale while maintaining enterprise-grade security and compliance.

Assumptions

1. Technology & Architecture

• Strategic Microsoft Alignment: Syensqo is committed to a long-term, Microsoft-first cloud strategy, utilizing Azure as the primary cloud platform and Microsoft 365 as the foundation for enterprise productivity.

• Platform Longevity: Microsoft Entra External ID will remain the strategic platform for B2B identity management throughout the planning horizon (minimum 3–5 years). No material shifts are anticipated in Microsoft's roadmap that would deprecate its core external identity capabilities.

• Standardization of Protocols: Open identity standards—specifically SAML 2.0, OIDC (OpenID Connect), and SCIM (System for Cross-domain Identity Management)—will continue to serve as the primary, supported integration mechanisms across SAP, Salesforce, and other enterprise SaaS platforms.

• Infrastructure Viability: Azure infrastructure and managed services (e.g., Azure Logic Apps, Function Apps) required for custom extensions will remain available at current or competitive pricing models.

2. Organizational & Operational

• Dual-Platform Competency: The organization will establish and fund the necessary training to operate a dual-platform identity landscape. The IAM team will maintain its existing SailPoint expertise for internal employee governance while developing new, dedicated competency in Microsoft Entra and SCIM provisioning for external users.

• Cultural Adoption of BYOI: Business stakeholders and external partners will actively accept and adopt the Bring Your Own Identity (BYOI) model. This requires a recognized cultural shift and targeted change management, as legacy, locally managed passwords for external users will be deprecated in favor of federated authentication.

• Process Standardization: Business units will agree to re-engineer their localized, manual external onboarding and offboarding processes to align with Entra's standardized lifecycle workflows, abandoning legacy manual workarounds.

3. Financial & Commercial

• Licensing Stability: Microsoft Entra ID Governance licensing costs—specifically the Monthly Active User (MAU) billing model for guests—will remain within acceptable, predictable bounds. No material price increases beyond standard annual inflation are anticipated by Microsoft.

• Operational Funding: Internal IT and security teams accept the operational overhead of managing a segmented identity governance model (SailPoint internally, Entra externally) as a strategic necessity.

• Program Budget: The organization has allocated sufficient capital and operational budget to fund both the initial consolidation effort (moving identities from SAP IAS and Salesforce into Entra) and the ongoing operational overhead for the planned 5-year period.

4. Risk & Compliance

• Data Residency & Privacy: Microsoft Entra External ID currently meets, and will continue to meet, all applicable data residency, sovereignty, and regulatory requirements (e.g., GDPR, CCPA, and industry-specific mandates) across all geographies in which Syensqo operates.

• Regulatory Stability: No material regulatory changes are anticipated during the planning horizon that would restrict or prohibit cloud-based B2B identity management or federated authentication models.

• Continuous Compliance: Microsoft’s security posture, threat detection capabilities, and compliance certifications will remain at or above industry standards, continuously satisfying Syensqo's internal audit and external compliance requirements.

• Replaces a complex, high-effort IGA deployment with a pragmatic, executable operating model that fits within current resource and timeline boundaries.

• Strategic Deferment: Acknowledges the fragmented identity stores (SAP and Salesforce) while intentionally avoiding the creation of custom, point-to-point workarounds that would complicate future modernization.

• Retrofit Readiness: Enforces an architecture that establishes the local environments first, keeping the door open for a future overarching identity governance umbrella.

Recommendation

Recommendation: Implement Option C—Continue with the Manual Management of External Identities (As-Is) as a formal interim strategy. Supplier identities will continue to be managed manually within SAP Identity Authentication Service (IAS), and B2B customer identities will be managed independently within Salesforce Experience Cloud.

Strategic Rationale Given the strict timelines and limited available resources, attempting to deploy a fully managed IGA service for all external identities is not currently viable. Maintaining the current operating model requires no upfront capital investment and avoids the immediate, cross-functional disruption of a massive data cleanup and architectural re-engineering effort.

Crucially, this approach is designed to be transitional. By operating SAP IAS and Salesforce as distinct, standardized local environments, the organization retains the flexibility to layer a centralized IGA platform over these ecosystems at a later date. This deferred approach accepts short-term operational overhead in exchange for immediate project viability.

Background & Context

Syensqo operates within a complex, multi-tenanted enterprise environment. The organization currently manages over 30,000 external identities—including 15,000 to 20,000 suppliers and thousands of B2B customers—across multiple geographies and business units.

Historically, Syensqo relied on SailPoint Identity Governance as its primary IAM platform. However, SailPoint was architected primarily for internal employee lifecycles and has proven inadequate for the scale and unique requirements of managing B2B external identities.

While the ultimate goal is to move to a unified identity control plane, recent assessments of project timelines and IT resource availability have dictated a phased approach. The organization will temporarily maintain its siloed external identity stores (SAP IAS for suppliers, Salesforce for customers) to ensure business continuity and meet immediate delivery milestones, with the explicit understanding that a centralized identity platform will be retrofitted in a future phase.

Assumptions

1. Technology & Architecture

• Future Retrofit Viability: The data structures and manual workflows maintained within SAP IAS and Salesforce will be kept sufficiently standardized to allow for integration into a future IGA platform (e.g., via standard APIs or SCIM) without requiring a complete rebuild of the underlying identity repositories.

• Siloed Platform Stability: Both SAP IAS and Salesforce are robust enough to independently handle the anticipated volume of B2B identities without catastrophic performance degradation during the interim period.

2. Organizational & Operational

• Resource Availability for Manual Operations: Internal IT, Helpdesk, and administrative teams have the capacity to absorb the linear increase in manual provisioning, deprovisioning, and password reset tickets as the external user base grows.

• Future Capital Allocation: Leadership will allocate the necessary budget and resources in a future fiscal cycle to execute the complex data cleanup, mapping, and implementation required for the deferred IGA retrofit.

3. Risk & Compliance

• Risk Acceptance: The business formally accepts the increased security and compliance risks inherent in manual identity management (e.g., orphaned accounts, fragmented audit trails) for the duration of this interim phase.

• Compensating Controls: Internal audit and security teams will implement manual compensating controls (e.g., periodic spreadsheet-based access reviews) to mitigate the lack of automated governance.

Constraints

1. Operational & Functional Constraints

• Lack of Automation: There is no automated trigger or workflow to ensure the timely removal of access when a supplier or customer relationship ends, heavily relying on manual notification from relationship owners.

• Absence of Self-Service: Despite native capabilities in the underlying platforms, the current configuration lacks unified self-service, forcing all password resets, attribute updates, and access modifications through internal IT support.

2. Security & Compliance Constraints

• No Unified Security Baseline: SAP IAS and Salesforce operate under separate password policies, session management settings, and MFA rules. There is no centralized Conditional Access evaluating external user logins across the estate.

• Audit Fragmentation: Evidence of access approvals and account creation must be manually assembled from disjointed emails, IT tickets, and localized system logs, highly complicating compliance attestation.

3. Scalability Constraints

• Linear Overhead: With tens of thousands of identities, the manual approach has exhausted practical administrative limits. Business growth will directly correlate with a growing backlog of provisioning tasks or require continuous IT headcount increases.

Impacts

• Data Quality Degradation: Manual data entry across multiple systems will inevitably lead to typographical errors, inconsistent naming conventions, and duplicate accounts. This degrades data quality and will significantly increase the complexity of the data mapping effort required for the future IGA retrofit.

• Orphaned Account Accumulation: The lack of automated deprovisioning creates a compounding security vulnerability. A material percentage of the 30,000+ external identities will likely become orphaned over time, leaving active credentials exposed.

• Poor External User Experience: External partners interacting with multiple Syensqo systems will suffer from password fatigue and disjointed onboarding experiences due to the lack of Single Sign-On (SSO).

• Opportunity Cost: Highly skilled SAP and Salesforce administrators will be forced to spend significant time performing routine data entry and helpdesk tasks rather than executing higher-value platform optimizations.

Financial Impact Analysis

1. Immediate Cost Avoidance (CapEx)

• Zero Upfront Platform Costs: By deferring the IGA implementation, the organization avoids the immediate capital expenditure associated with purchasing new licensing (e.g., Microsoft Entra MAU billing) and the heavy professional services costs required for a complex deployment.

2. Ongoing & Hidden Operational Costs (OpEx)

• High Administrative Drain: The true cost of this model is absorbed into decentralized daily operations. IT administrator hours and helpdesk resources will be consumed by manual account creation, modification, deactivation, and external user password troubleshooting.

• Audit Preparation Overhead: The financial cost of internal labour required to manually gather, correlate, and prove compliance across disconnected systems during audit cycles will be substantial.

3. Deferred Technical Debt

• Future Implementation Premium: Retrofitting governance onto deeply entrenched, siloed identity stores may cost more than a greenfield deployment. The future IGA implementation may require heavily funded data cleanup effort and complex legacy permission mapping.

Business Rules

To mitigate the risks of this interim manual approach and prepare for the future IGA retrofit, the following rules must be strictly enforced:

1. Strict Identity Segregation

• Platform Boundaries: Supplier identities must be managed exclusively within SAP IAS. B2B customer identities must be managed exclusively within Salesforce. Cross-pollination or manual duplication of identities between these silos without strict business justification is prohibited unless business cases make sense.

2. Data Hygiene & Standardization

• Standardized Naming Conventions: All manual account creations must adhere to a strict, globally documented naming and attribute convention. This is critical to ensure identities can be programmatically matched and correlated when the overarching IGA solution is eventually deployed.

• Mandatory Attributes: No external account may be created without a valid external email address and a documented internal business sponsor.

3. Compensating Security Controls

• Manual Access Certifications: Business unit owners must conduct mandatory, bi-annual manual access reviews. IT will provide user exports from SAP IAS and Salesforce, and business owners must formally sign off on the continued necessity of each external account to mitigate the accumulation of orphaned credentials.

• Deactivation SLAs: A strict Service Level Agreement (SLA) must be established requiring relationship owners to notify IT within 48 hours of a supplier contract termination or B2B relationship end, triggering manual deprovisioning.

Options considered

Option A: Microsoft Identity Access Governance

1. Executive Recommendation Implement Microsoft Entra External ID and Entra ID Governance as the centralized identity control plane for all 30,000+ external (B2B) identities. SailPoint will be retained strictly for internal employee governance, establishing a dual-platform architecture.

2. Problem Statement & Context The organization currently manages a rapidly growing base of external identities (partners, vendors, clients) using a mix of SailPoint, manual processes, and point-to-point integrations across SAP and Salesforce. SailPoint is currently architected for internal lifecycles and there are no future plans to use SailPoint for external identities. This fragmentation creates security risks, compliance blind spots, and severe operational bottlenecks for IT.

3. Strategic Rationale

• Microsoft-First Consolidation: Natively embeds external identity management within the existing Azure security fabric, extending enterprise protections (like Conditional Access) to B2B users without custom connectors.

• Scalable "Bring Your Own Identity" (BYOI): Shifts the authentication burden to the partner’s identity provider, drastically reducing helpdesk overhead while maintaining strict logical isolation from the core employee directory.

• Automated SaaS Provisioning: Acts as an identity broker, leveraging open standards like SCIM, SAML, and OIDC to automatically provision and revoke downstream access in SAP and Salesforce.

4. Key Assumptions & Constraints

• Dual-Platform Overhead: IT and IAM teams must upskill to operate a bifurcated governance model (SailPoint for internal, Entra for external), requiring consolidated reporting for audit purposes.

• Architectural Nuances: Native Entra provisioning directly into SAP ERP is unsupported; integrations must be mediated through SAP Cloud Identity Services (IAS). Complex workflows may require custom Azure Logic Apps.

• Financial Variability: Microsoft's Monthly Active User (MAU) billing model for guest governance means operational costs will fluctuate month-to-month based on the volume of billable governance events (like access reviews).

5. Mandatory Business Rules & Impacts

• Strict Segregation: External users must only reside in Entra (classified as "Guests"), and internal users must only reside in SailPoint.

• Package-Based, Time-Bound Access: Direct group or role assignments are prohibited. Access is granted exclusively via Entra Access Packages, which require an internal sponsor and a defined expiration date.

• Automated Lifecycles: All downstream provisioning to SAP and Salesforce must be fully automated via Entra. Manual creation or removal of external accounts in downstream systems is forbidden.

Option B: Use SailPoint to Manage All External Identities

Under this option, the organization would leverage its existing SailPoint IdentityNow (or IdentityIQ) deployment to serve as the identity governance and administration (IGA) platform for all external identities. This encompasses both the B2B supplier accounts currently held in SAP IAS and the B2B customer accounts managed within Salesforce.

SailPoint is a mature, market-leading identity governance platform. It provides comprehensive provisioning, access request workflows, certification campaigns, separation-of-duties enforcement, and lifecycle management capabilities. On paper, it comfortably meets the functional requirements for managing external identities.

However, functional capability alone does not make SailPoint the optimal choice for this specific use case. Several material factors—primarily strategic misalignment and architectural complexity—weigh against this option, presenting a compelling case for looking elsewhere.

Functional Assessment

SailPoint can natively fulfil the core requirements of external identity management:

• Automated provisioning and deprovisioning of external user accounts across target systems.

• Access request and approval workflows for external user onboarding.

• Access certification campaigns to periodically review and attest external user entitlements.

• Policy enforcement, including separation of duties and role-based access control.

• Audit logging and reporting for compliance and governance purposes.

In isolation, these capabilities make SailPoint a highly credible candidate. The challenge lies not in what SailPoint can do, but in whether it is the right strategic investment for the organization's future state.

Strategic Misalignment

SailPoint is not positioned as the strategic IAM solution for this organization. The business has already established its direction of travel toward the Microsoft Entra platform as the primary identity provider and governance layer. This strategic decision reflects the organization’s deep investment in the Microsoft ecosystem across infrastructure, productivity, security, and cloud services.

Selecting SailPoint for external identity management would run directly counter to this strategic direction. It requires committing further budget, skills, and operational capacity to a platform that is not the long-term strategic focus. Every pound spent on SailPoint licensing, advanced configuration, and specialist resources is a pound diverted away from the platform that will form the backbone of the organization’s future identity architecture.

From an architectural governance perspective, introducing SailPoint as the external identity layer alongside Microsoft Entra for internal identities creates a dual-platform IAM landscape. This increases architectural complexity, requires maintaining two sets of operational expertise, and fragments the enterprise identity management narrative.

Integration Complexity (Multi-Vendor Landscape)

SailPoint does offer supported, out-of-the-box connectors for both target platforms:

• SAP IAS: SailPoint provides a standard SAP Cloud Identity Services integration capable of managing users and groups within SAP IAS.

• Salesforce: The standard SailPoint Salesforce connector natively supports the management of external Community and Experience Cloud users, including profile and permission set assignments.

However, the availability of these connectors does not eliminate the implementation burden. Leveraging them still introduces significant integration challenges:

• Advanced Configuration: While ground-up coding is not required, mapping complex external user attributes and business logic between SAP, Salesforce, and SailPoint requires specialized SailPoint engineering expertise.

• Vendor Dependency: The organization remains at the mercy of three different vendors (SailPoint, SAP, and Salesforce) for API updates, connector patching, and version compatibility.

• Operational Silos: Managing external identities in SailPoint while managing internal identities in Entra ID prevents the organization from establishing a unified, single-pane-of-glass view for enterprise-wide access routing and identity risk.

Ecosystem and Vendor Alignment

The organization operates heavily within a Microsoft environment, built on Azure, Microsoft 365, and the broader Microsoft security and identity stack. Microsoft Entra ID already serves as the identity provider for the internal workforce. Choosing SailPoint for external identities introduces a competing governance platform that does not natively benefit from the shared security context, telemetry, and unified management plane provided by the Microsoft ecosystem.

By contrast, an Entra-centric approach allows for native integration with the tools already managing internal identities, Conditional Access policies, security monitoring, and compliance. Selecting SailPoint forfeits these consolidation advantages.

Cost Considerations

The total cost of ownership (TCO) for the SailPoint option extends well beyond basic platform capability:

• SailPoint platform licensing (per-identity or subscription model for external users).

• Specialist SailPoint engineering resources (internal or contracted) for advanced connector configuration and business logic mapping.

• Ongoing operational overhead to maintain a secondary identity platform.

• The opportunity cost of investing in a non-strategic platform instead of consolidating on Microsoft Entra.

When these costs are aggregated and compared against the investment required for a Microsoft-native solution—which benefits from existing licensing agreements, native ecosystem integration, and familiar tooling—the SailPoint option becomes difficult to justify financially.

Summary Assessment: Option B

Option C: Decentralized Management with API Improvements (No IGA)

Under this option, the organization adopts a decentralized but highly optimized operating model. By prioritizing native platform capabilities and modern API integrations, the business drives immediate onboarding efficiencies across both external ecosystems. This approach modernizes both SAP Identity Authentication Service (IAS) and Salesforce Experience Cloud independently, achieving operational gains without much upfront capital investment or organizational change management required to deploy a centralized Identity Governance and Administration (IGA) platform.

While SAP IAS and Salesforce will continue to operate as fragmented identity stores, this approach delivers tangible, value improvements to both supplier and B2B customer onboarding processes.

Preserving Future Flexibility

Managing SAP and Salesforce locally inherently creates a decentralized architecture, but it strategically preserves options for the future. By establishing mature, automated local environments first, the organization effectively lays the groundwork for a future overarching governance implementation. If the business decides to introduce an enterprise-wide IGA solution later, the local automation and delegated structures established within these platforms will already be functioning efficiently. Future integrations become a matter of applying central oversight to processes that are already technically optimized.

Operating Model (Target State): SAP IAS

This approach shifts the organization away from manual administration for its 15,000 to 20,000 external suppliers, introducing an automated, self-service-oriented model:

• Automated Provisioning: Supplier creation is triggered directly from SAP S/4HANA via the SAP Cloud Identity Services API, entirely removing the need for manual user creation by internal SAP Security administrators.

• Empowered Delegated Administration: Upon creation, an automated email empowers a designated external Supplier Administrator. By logging into IAS, these admins take ownership of onboarding, managing, and maintaining their own users, effectively crowdsourcing the administrative effort.

• Federated SSO: Supplier Admins gain the flexibility to request federated Single Sign-On (SSO) to integrate their own corporate credentials.

• Automated Access Management: IAS APIs are leveraged to dynamically apply IAS Groups for user access, removing routine enforcement tasks from internal IT.

SAP IAS Advantages and Disadvantages

Advantages:

• Scalability: Reduces internal IT bottlenecks, allowing supplier onboarding to scale seamlessly with business growth.

• Partner Autonomy: Improves the partner experience by giving them direct control over their own workforce's access without waiting on IT helpdesk tickets.

• Process Velocity: Automated triggers from S/4HANA ensure that access is provisioned the moment a supplier contract is finalized in the ERP.

Disadvantages:

• The "Orphaned Account" Risk: The delegated model relies entirely on external Supplier Admins to promptly deactivate users who leave their company. Without central oversight, this creates a high risk of active credentials lingering indefinitely.

• Audit Blind Spots: Gathering evidence for compliance audits (e.g., proving who approved a specific user's access) is difficult when administration is delegated externally without an overarching governance logging tool.

• Extra Tenant Needed: A new IAs tenant will need to be procured to ensure all external ID's are held in the IAS tenant. Additional cost to ensure no mixture of Internal & external ID's

Operating Model (Target State): Salesforce

Moving away from the legacy approach of email-driven or spreadsheet-initiated provisioning, the organization will implement native Salesforce automation to handle thousands of B2B customer identities:

• Automated Self-Registration: Utilizing Salesforce Flow Builder, the organization will expose intelligent self-registration pages. These flows automatically match registrant email domains to existing B2B Accounts and route approval requests to the appropriate internal account owner.

• Just-in-Time (JIT) Provisioning: For larger B2B clients utilizing federated SSO, Salesforce will intercept SAML assertions via JIT Provisioning to automatically create user records and assign permissions on the fly during their first login.

• Delegated External Administration: Similar to the SAP model, designated "Super Users" at client organizations will be granted external delegated admin rights to manage their own colleagues within the Experience Cloud portal.

Salesforce Advantages and Disadvantages

Advantages:

• Frictionless Customer Experience: JIT provisioning and automated self-registration ensure customers can access portals, catalogs, and support immediately, enhancing brand perception.

• Contextual Access: By leveraging Salesforce User Access Policies, permissions are automatically tied to the user's CRM data (e.g., tier, region, purchased products), ensuring highly accurate, dynamic entitlement mapping.

• Reduced Support Costs: Shifting routine password resets and user creation to customer "Super Users" drastically lowers ongoing operational costs.

Disadvantages:

• Data Silos and Duplication: Because Salesforce and SAP remain disconnected, an external user who acts as both a supplier and a B2B customer will have two entirely separate identities, requiring them to manage two profiles.

• Inconsistent Security Posture: Internal IT must manually dual-maintain security policies. If the organization decides to mandate a new Multi-Factor Authentication (MFA) requirement, it must be configured, tested, and deployed twice—once in Salesforce and once in SAP IAS.

Considerations and Inherent Risks of Decentralization

While the API improvements deliver excellent operational efficiency, maintaining a decentralized architecture does introduce certain visibility and governance trade-offs. Relying on fragmented systems means that cross-platform reporting and unified lifecycle management require more manual coordination

Impacts

Architectural & Operational Impacts

Transitioning external identity management to Microsoft Entra introduces several significant impacts across the organization's architecture, application ecosystems, and operational teams.

1. Identity Architecture & Infrastructure

• Entra Directory Structure: External identities will be governed via Microsoft Entra External ID. This establishes a clear security boundary for guest users while enabling unified Conditional Access policies across the Microsoft estate.

• Provisioning Pipelines: The decentralized, manual provisioning workflows currently operating in silos must be re-architected. Entra will act as the centralized identity orchestration engine, pushing identity and access data to downstream systems via SCIM (System for Cross-domain Identity Management) and API connectors.

2. SAP Ecosystem Impact

• SAP User Provisioning: All external user provisioning to SAP systems (including User Master records, role assignments, and system access) must be re-routed through an automated pipeline: Entra → SAP Cloud Identity Services → SAP.

• SAP Access Reviews & Governance: Attestation workflows for external SAP access will shift from manual tracking to automated Entra ID Governance access reviews.

• SAP Compliance & Audit: SAP audit trails, system logs, and compliance reports must be reconfigured to reflect identity state changes sourced centrally from Entra rather than relying on decentralized SAP IAS logs.

• SAP On-Premises vs. Cloud Maturity: If the organization operates a mix of on-premises SAP ERP and cloud-based solutions (e.g., SuccessFactors, SAP Analytics Cloud), the SCIM integration maturity for each platform must be evaluated individually to ensure automated provisioning is fully supported.

3. Salesforce Ecosystem Impact

• Salesforce User Provisioning: External user provisioning to Salesforce (specifically Experience Cloud/Communities) must be implemented via SAML/OIDC Single Sign-On. While Entra provides a Salesforce SCIM connector, managing complex external community profiles often requires supplementary Salesforce automation (e.g., Salesforce Flows) to handle specific lifecycle nuances.

• Salesforce License Consumption: Automated provisioning must be tightly governed through Entra access packages to control the consumption of specific Salesforce licenses (e.g., Partner Community, Customer Community). Strict license planning is required to avoid cost overruns.

• Salesforce Metadata & Configuration: Entra attribute mappings must precisely align with custom Salesforce user attributes and profile assignments. Any mismatch will require data transformation logic prior to provisioning.

4. Data Consolidation & Cutover

• Legacy External User Data Consolidation: All historical external user records and attributes currently stored manually within SAP IAS and Salesforce must be extracted, cleansed, and consolidated into Entra. Data validation is critical to prevent access control failures during the cutover.

• Access Rights Recreation: All existing external group memberships, profile assignments, and role structures must be translated and re-created within Entra ID Governance as formal Access Packages.

• Historical Audit Trails: Historical audit logs and identity change records from SAP IAS and Salesforce should be extracted and securely archived for compliance, forensic, and continuity purposes prior to cutover.

5. Organizational & Governance

• Identity Governance Team Evolution: The existing IAM team must upskill to manage a dual-platform environment. While their SailPoint expertise remains essential for governing internal employees, they must develop parallel competency in Entra External ID, SCIM provisioning, and Entitlement Management for B2B users.

• Business Process Re-engineering: Manual onboarding requests (e.g., via email or helpdesk tickets) must be completely re-engineered to leverage Entra's self-service access request portals and internal sponsor approval workflows.

• Change Management: External partners and suppliers must be thoroughly communicated with and trained on new authentication methods (e.g., BYOI federated login, MFA registration), as legacy, localized password-based access will be phased out.

• Governance Council: A cross-functional governance council must be established to define Entra-specific governance parameters, including access review cadences, sponsor hierarchies, and external data quality standards.

6. Security & Compliance

• Conditional Access Design: New Entra Conditional Access policies must be designed and strictly scoped to guest users to enforce Zero Trust principles (e.g., enforcing MFA, risk-based adaptive authentication, and session limits).

• Audit & Logging Integration: All Entra identity events, SCIM provisioning actions, and access review results must be routed to Azure Log Analytics and integrated into the organization's SIEM platform, running in parallel with existing SailPoint telemetry.

• Compliance Attestation: Audit teams must validate that the new Entra External ID configuration meets all applicable regulatory requirements (e.g., GDPR, SOC 2, industry mandates) across all operating regions before go-live.

7. In-Flight Projects & Dependencies

• Project Alignment: Any active IT projects involving external portal development, access control, or supplier onboarding must be assessed for impact and strictly aligned with the Entra migration timeline.

• Platform Upgrades: Planned SAP or Salesforce platform upgrades should be carefully sequenced to avoid resource collisions or technical conflicts with the Entra SCIM deployment.

Financial Impact

Financial Impact Analysis

The decision to establish Microsoft Entra as the centralized platform for external identity management introduces a shift in the organization's cost structure. The financial impact can be categorized into implementation, licensing, operations, and resulting long-term efficiencies.

1. Implementation & Consolidation Costs

The initial capital expenditure and resource allocation required to deploy this architecture fall into three main pillars:

• Deployment & Configuration: Costs associated with professional services and internal engineering required to design and configure the Entra External ID and Entra ID Governance environments. This includes setting up the tenant, designing Conditional Access policies, building access packages, configuring lifecycle workflows, and establishing SCIM-based automated provisioning to downstream applications like SAP and Salesforce.

• Data Consolidation & Remediation: The effort required to extract the baseline of roughly 30,000 external identities currently scattered across SAP IAS and Salesforce, cleanse the data to meet new centralized quality standards, and properly map their attributes, entitlements, and governance policies into Entra.

• Training & Upskilling: The investment necessary to train the IAM team and IT operations staff, ensuring they develop the required competency in Entra ID Governance administration to operate the new external identity architecture effectively alongside their existing internal tools.

2. Licensing & Subscription Costs

The external identity model will utilize a consumption-based structure:

• Monthly Active User (MAU) Billing: The organization must maintain a Microsoft Entra ID P1 or P2 tenant-level subscription and link an active Azure subscription to enable the Microsoft Entra External ID MAU billing model.

• Governance Add-on Variability: Crucially, the Entra ID Governance for Guests add-on is billed based on guest MAU rather than fixed per-seat licensing. While cost-efficient during periods of low activity, this introduces financial variability. With an existing baseline of 30,000 external users, costs will fluctuate month-to-month based on the volume of guests triggering billable governance events, requiring active monitoring and budget forecasting.

3. Ongoing Operational Costs

The organization will carry the operational overhead of maintaining a segmented identity governance architecture (SailPoint for internal, Entra for external):

• Dual-Platform Overhead: This includes maintaining two separate sets of operational procedures and the manual effort required to consolidate compliance reporting across both environments for auditors.

• Operational Offsets: This overhead is heavily offset by the reduction in manual IT support tickets. Entra’s entitlement management and automation capabilities—specifically the BYOI (Bring Your Own Identity) model, self-service access requests, and delegated administration—will significantly reduce the day-to-day administrative burden previously required to manage external users in SAP and Salesforce.

4. Cost Offsets & Long-Term Efficiencies

Over time, this architectural decision is expected to deliver a strong return on investment (ROI) through modernization and automation:

• Process Automation: Retiring the manual provisioning and deprovisioning processes currently handled by internal administrators in SAP and Salesforce eliminates a significant drain on operational resources.

• Maximizing Ecosystem Investment: By aligning natively with the organization's existing Microsoft investment, the business leverages tools built for this exact purpose rather than attempting to force a third-party platform to manage external users. The ultimate financial efficiency will scale proportionally with the volume of identity workflows the organization successfully automates.

Business Rules

The following business rules dictate the architecture, governance, and operational procedures for managing external identities. These rules are mandatory and must be strictly enforced through platform configuration and automated policies.

1. Architecture & Platform Boundaries

• Strict Platform Segregation: All external (B2B) identities—including partners, vendors, clients, and non-employees—must be managed exclusively within Microsoft Entra External ID. SailPoint is strictly reserved for internal (employee) identity governance. An identity cannot be simultaneously governed by both platforms.

• Mandatory Guest Classification: Every external identity onboarded into the Entra tenant must be assigned a userType of Guest. Provisioning an external user as a Member within the core employee directory is strictly prohibited. This ensures proper architectural segregation and supports accurate billing mechanisms.

2. Authentication & Access Control

• Bring Your Own Identity (BYOI) as Default: External users must authenticate using their own organization's identity provider. Federated authentication via SAML 2.0 or OIDC is the default requirement. Email One-Time Passcode (OTP) or local accounts are permitted only as documented, periodically reviewed exceptions for partners lacking compatible identity providers.

• Package-Based Access Only: Direct role or group assignments for external identities are prohibited. All access to downstream systems (SAP, Salesforce, Microsoft 365, etc.) must be granted via defined Entra ID Governance Access Packages. These packages must enforce specific approval requirements, durations, and review cadences.

• Mandatory Sponsorship & Approval: No external identity may be onboarded without a designated internal sponsor. Every access package policy must enforce at least one approval stage requiring sign-off from a named sponsor or delegated business unit approver. Self-approval by external users is not permitted.

• Time-Bound Access: Open-ended or permanent access is strictly prohibited for B2B users. Every access package must carry a defined expiration date. Continued access must be re-certified via recurring access reviews by the sponsor. Failure to complete a review within the active window must trigger an automatic revocation of access.

3. Lifecycle & Automated Provisioning

• Automated Lifecycle Enforcement: External identity lifecycle events (onboarding, modification, and offboarding) must be driven entirely by Entra ID Governance lifecycle workflows. When an external user's contract ends or their access package expires unrenewed, their access to all systems must be automatically revoked, and their guest account must be disabled or deleted.

• Automated Downstream Provisioning: Provisioning and deprovisioning in downstream systems must be automated through Entra (e.g., via SCIM synchronization for Salesforce and SAP Cloud Identity Services). Manual creation or removal of external accounts directly within SAP or Salesforce is prohibited. Entra serves as the sole source of truth.

4. Governance, Compliance & Operations

• Mandatory Billing Enablement: The Microsoft Entra ID Governance for Guests add-on must remain continuously linked to an active Azure subscription. Permitting this linkage to lapse disables critical governance features (access reviews, entitlement policies) and constitutes a critical operational failure.

• Consolidated Audit Reporting: Identity governance evidence must be seamlessly producible across both SailPoint (internal) and Entra (external). A consolidated reporting process must be maintained to provide auditors with a complete, holistic view of the organization's identity posture without requiring disjointed platform interrogations.

• Strict Data Quality Standards: External records must meet minimum data quality thresholds before access is provisioned. At a minimum, this includes a verified external email address, mapped organizational affiliation, a designated internal sponsor, and all required downstream attributes. Non-compliant records must be quarantined for remediation.

1. Executive Recommendation Implement Microsoft Entra External ID and Entra ID Governance as the centralized identity control plane for all 30,000+ external (B2B) identities. SailPoint will be retained strictly for internal employee governance, establishing a dual-platform architecture.

2. Problem Statement & Context The organization currently manages a rapidly growing base of external identities (partners, vendors, clients) using a mix of SailPoint, manual processes, and point-to-point integrations across SAP and Salesforce. SailPoint is currently architected for internal lifecycles and there are no future plans to use SailPoint for external identities. This fragmentation creates security risks, compliance blind spots, and severe operational bottlenecks for IT.

3. Strategic Rationale

• Microsoft-First Consolidation: Natively embeds external identity management within the existing Azure security fabric, extending enterprise protections (like Conditional Access) to B2B users without custom connectors.

• Scalable "Bring Your Own Identity" (BYOI): Shifts the authentication burden to the partner’s identity provider, drastically reducing helpdesk overhead while maintaining strict logical isolation from the core employee directory.

• Automated SaaS Provisioning: Acts as an identity broker, leveraging open standards like SCIM, SAML, and OIDC to automatically provision and revoke downstream access in SAP and Salesforce.

4. Key Assumptions & Constraints

• Dual-Platform Overhead: IT and IAM teams must upskill to operate a bifurcated governance model (SailPoint for internal, Entra for external), requiring consolidated reporting for audit purposes.

• Architectural Nuances: Native Entra provisioning directly into SAP ERP is unsupported; integrations must be mediated through SAP Cloud Identity Services (IAS). Complex workflows may require custom Azure Logic Apps.

• Financial Variability: Microsoft's Monthly Active User (MAU) billing model for guest governance means operational costs will fluctuate month-to-month based on the volume of billable governance events (like access reviews).

5. Mandatory Business Rules & Impacts

• Strict Segregation: External users must only reside in Entra (classified as "Guests"), and internal users must only reside in SailPoint.

• Package-Based, Time-Bound Access: Direct group or role assignments are prohibited. Access is granted exclusively via Entra Access Packages, which require an internal sponsor and a defined expiration date.

• Automated Lifecycles: All downstream provisioning to SAP and Salesforce must be fully automated via Entra. Manual creation or removal of external accounts in downstream systems is forbidden.

Summary Assessment: Recommended Approach (Microsoft Entra)

Option B: Use SailPoint to Manage All External Identities

Under this option, the organization would leverage its existing SailPoint IdentityNow (or IdentityIQ) deployment to serve as the identity governance and administration (IGA) platform for all external identities. This encompasses both the B2B supplier accounts currently held in SAP IAS and the B2B customer accounts managed within Salesforce.

SailPoint is a mature, market-leading identity governance platform. It provides comprehensive provisioning, access request workflows, certification campaigns, separation-of-duties enforcement, and lifecycle management capabilities. On paper, it comfortably meets the functional requirements for managing external identities.

However, functional capability alone does not make SailPoint the optimal choice for this specific use case. Several material factors—primarily strategic misalignment and architectural complexity—weigh against this option, presenting a compelling case for looking elsewhere.

Functional Assessment

SailPoint can natively fulfil the core requirements of external identity management:

• Automated provisioning and deprovisioning of external user accounts across target systems.

• Access request and approval workflows for external user onboarding.

• Access certification campaigns to periodically review and attest external user entitlements.

• Policy enforcement, including separation of duties and role-based access control.

• Audit logging and reporting for compliance and governance purposes.

In isolation, these capabilities make SailPoint a highly credible candidate. The challenge lies not in what SailPoint can do, but in whether it is the right strategic investment for the organization's future state.

Strategic Misalignment

SailPoint is not positioned as the strategic IAM solution for this organization. The business has already established its direction of travel toward the Microsoft Entra platform as the primary identity provider and governance layer. This strategic decision reflects the organization’s deep investment in the Microsoft ecosystem across infrastructure, productivity, security, and cloud services.

Selecting SailPoint for external identity management would run directly counter to this strategic direction. It requires committing further budget, skills, and operational capacity to a platform that is not the long-term strategic focus. Every pound spent on SailPoint licensing, advanced configuration, and specialist resources is a pound diverted away from the platform that will form the backbone of the organization’s future identity architecture.

From an architectural governance perspective, introducing SailPoint as the external identity layer alongside Microsoft Entra for internal identities creates a dual-platform IAM landscape. This increases architectural complexity, requires maintaining two sets of operational expertise, and fragments the enterprise identity management narrative.

Integration Complexity (Multi-Vendor Landscape)

SailPoint does offer supported, out-of-the-box connectors for both target platforms:

• SAP IAS: SailPoint provides a standard SAP Cloud Identity Services integration capable of managing users and groups within SAP IAS.

• Salesforce: The standard SailPoint Salesforce connector natively supports the management of external Community and Experience Cloud users, including profile and permission set assignments.

However, the availability of these connectors does not eliminate the implementation burden. Leveraging them still introduces significant integration challenges:

• Advanced Configuration: While ground-up coding is not required, mapping complex external user attributes and business logic between SAP, Salesforce, and SailPoint requires specialized SailPoint engineering expertise.

• Vendor Dependency: The organization remains at the mercy of three different vendors (SailPoint, SAP, and Salesforce) for API updates, connector patching, and version compatibility.

• Operational Silos: Managing external identities in SailPoint while managing internal identities in Entra ID prevents the organization from establishing a unified, single-pane-of-glass view for enterprise-wide access routing and identity risk.

Ecosystem and Vendor Alignment

The organization operates heavily within a Microsoft environment, built on Azure, Microsoft 365, and the broader Microsoft security and identity stack. Microsoft Entra ID already serves as the identity provider for the internal workforce. Choosing SailPoint for external identities introduces a competing governance platform that does not natively benefit from the shared security context, telemetry, and unified management plane provided by the Microsoft ecosystem.

By contrast, an Entra-centric approach allows for native integration with the tools already managing internal identities, Conditional Access policies, security monitoring, and compliance. Selecting SailPoint forfeits these consolidation advantages.

Cost Considerations

The total cost of ownership (TCO) for the SailPoint option extends well beyond basic platform capability:

• SailPoint platform licensing (per-identity or subscription model for external users).

• Specialist SailPoint engineering resources (internal or contracted) for advanced connector configuration and business logic mapping.

• Ongoing operational overhead to maintain a secondary identity platform.

• The opportunity cost of investing in a non-strategic platform instead of consolidating on Microsoft Entra.

When these costs are aggregated and compared against the investment required for a Microsoft-native solution—which benefits from existing licensing agreements, native ecosystem integration, and familiar tooling—the SailPoint option becomes difficult to justify financially.

Summary Assessment: Option B

Option C: Continue with Manual Management of External Identities (As-Is)

Under this option, the organization would maintain the current operating model for external identity management. Supplier identities would continue to be created, maintained, and deactivated manually within SAP Identity Authentication Service (IAS). B2B customer identities would continue to be managed independently and manually within Salesforce. No centralized identity platform would be introduced upfront, and no cross-system automation or governance tooling would be implemented at this stage.

This option represents the status quo. While it requires no upfront capital investment and defers any immediate organizational change management effort, it carries significant and compounding risks that must be clearly understood before it can be considered a viable long-term strategy.

The Strategic Caveat: The Opportunity to Retrofit IGA

While managing SAP IAS and Salesforce locally inherently creates a fragmented, decentralized solution, this approach does leave the door open for future flexibility. By establishing the local environments first, the organization retains the option to retrofit an overarching Identity Governance and Administration (IGA) solution—such as Microsoft Entra Identity Governance or another capable third-party IGA platform—over the SAP BTP and Salesforce ecosystems at a later date.

Crucially, however, this deferred approach is not a minor tweak. Implementing a centralized IGA solution after the fact requires extensive planning and cross-functional alignment. Retrofitting governance onto deeply entrenched, siloed identity stores often necessitates massive data cleanup efforts, complex mapping of legacy permissions, and significant architectural re-engineering to align the disparate platforms under a single governance umbrella.

Current Operating Model

The current state of external identity management is characterized by the following siloed processes:

SAP IAS – Supplier Identities

• An estimated 15,000 to 20,000 external supplier identities are managed within SAP IAS.

• Each supplier account is created manually by internal administrators. This includes setting up the user record, assigning the appropriate authentication method, and configuring access to the relevant SAP applications.

• When a supplier relationship ends, deactivation of the account relies entirely on manual notification and action. There is no automated trigger or workflow to ensure timely removal.

• In the current configuration, suppliers lack self-service capabilities to manage their profiles or credentials, despite SAP IAS offering native self-registration and profile management features. Consequently, password resets, attribute updates, and access modifications are heavily reliant on manual administrative support.

Salesforce – B2B Customer Identities

• Thousands of B2B customer identities are maintained within Salesforce, typically within Experience Cloud (Communities).

• Account provisioning is handled manually, often initiated through email requests or spreadsheet-based onboarding processes.

• Even though Salesforce Experience Cloud supports delegated administration and self-registration, the current process relies on internal administrators to execute profile updates, permission changes, and deactivations.

• There is no centralized view of a customer’s identity status across Salesforce and any other enterprise systems they may access.

Why This Option Is Not Sustainable

Even with the possibility of retrofitting an IGA solution later, continuing with the current manual, decentralized approach exposes the organization to a range of operational, security, compliance, and financial risks that will only intensify as the external user population scales.

1. Human Error and Data Quality Degradation Manual identity management is inherently error-prone. When administrators create and modify thousands of accounts by hand across two separate systems, mistakes are inevitable. These errors manifest as:

• Accounts created with excessive permissions, granting external users access to data or functions outside their required scope.

• Typographical errors in user attributes (names, email addresses, identifiers) that degrade data quality and make it incredibly difficult to correlate identities across systems when a future IGA retrofit is attempted.

• Duplicate accounts created when an existing identity is not found during a manual search.

• Inconsistent naming conventions and attribute values between SAP IAS and Salesforce, obstructing cross-system reporting and auditing.

2. Orphaned and Dormant Accounts This is one of the most critical security vulnerabilities of manual identity management. When a supplier contract expires, a customer relationship ends, or an individual changes roles, there is no automated mechanism to detect this context change and deactivate the corresponding access. In practice, this means the organization is actively carrying a significant number of orphaned accounts—active credentials belonging to individuals who no longer have a legitimate business relationship with the company. Each orphaned account is a potential entry point for unauthorized access. With 15,000 to 20,000 supplier accounts alone, even a 5% orphan rate represents a material security exposure.

3. Audit and Compliance Failure Regulatory frameworks and internal audit functions increasingly require organizations to demonstrate effective, provable controls over system access. Manual identity management fails to meet these standards:

• Fragmented Audit Trails: There is no centralized log detailing who created an account, who approved it, and what access was granted. Evidence must be manually assembled from disjointed emails, IT tickets, and spreadsheets.

• No Access Certification: There is no systematic mechanism for relationship owners to periodically review and attest that external users still require their current access levels.

• High Probability of Audit Findings: Auditors will inevitably flag the lack of automated lifecycle governance over third-party identities as a critical observation.

4. Scalability Has Reached Its Limit With tens of thousands of external identities spread across systems, the current manual approach has exhausted the practical limits of administrative capacity. As the business grows, the volume of external identities will increase, but manual processes will not yield efficiency gains. This results in either a growing backlog of provisioning tasks (delaying partner onboarding) or a necessary, linear increase in IT headcount simply to maintain the status quo.

5. No Unified Security Baseline Because security policies are defined and enforced independently within each silo, the organization lacks a cohesive security posture:

• SAP IAS and Salesforce operate under separate password policies, session management settings, and multi-factor authentication (MFA) rules.

• There is no centralized Conditional Access or risk-based authentication capability evaluating external user logins across the digital estate.

• In the event of a security incident, there is no "single pane of glass" to investigate cross-platform sign-in activity.

6. Poor User Experience for External Stakeholders External partners interacting with multiple systems must juggle separate credentials. The lack of Single Sign-On (SSO) and unified self-service creates:

• Password fatigue, leading to weak or reused credentials.

• A high volume of routine password reset tickets directed to internal IT support.

• Unnecessary friction during onboarding, projecting a disjointed organizational image to external partners.

7. Hidden Operational Costs The true cost of manual identity management is frequently underestimated because it is absorbed into decentralized, day-to-day operational activities. However, the quantifiable drain on resources is substantial:

.

Summary of Risks: Option C

Evaluation

Option A

Decision Parameter	Pros	Cons	Overall Assessment
Feasibility & Functional Fit	• Purpose-built for external scale (30,000+ users). • Natively supports BYOI (Bring Your Own Identity), automated lifecycles, and access packages.	• Deeply nested or highly customized legacy approval workflows may require supplementary custom Azure Logic Apps.	High. Highly capable of handling the current and future external identity scale natively, replacing error-prone manual steps with automated enforcement.
Complexity (Architecture & Integration)	• Centralizes external identities within the existing Azure fabric. • Out-of-the-box SCIM support for downstream applications like Salesforce.	• Based on the current set up, this would Establish a dual-platform architecture (SailPoint internally, Entra externally)	Moderate. Consolidation drastically simplifies the Microsoft estate, though downstream SaaS integrations and dual-platform operations introduce specific technical nuances.
Cost & Effort to Implement	• Maximizes ROI on the organization's existing Microsoft cloud investments. • Delivers massive long-term reduction in IT helpdesk costs through self-service and automation.	• Requires upfront effort for data cleansing, extraction, and platform configuration. • Monthly Active User (MAU) billing for guest governance introduces month-to-month financial variability.	Strong ROI. The upfront implementation effort and training are heavily offset by significant long-term operational savings, automated compliance, and risk reduction.
Ongoing Operational Impact & Cost	• Drastically reduces manual provisioning tickets. • Shifts the authentication and credential management burden to external partners.	• Requires the IAM team to upskill and maintain dual-platform competency + Additional headcount will be needed to support this • Managing complex access packages may remain an IT task due to UI limitations for business users.	Net Positive. Replaces manual administrative busywork with automated governance, transforming the IAM team's role from execution to oversight.
Program Principles & Deviations	• Strictly aligns with Zero Trust, least privilege, and Microsoft-first consolidation principles. • Guarantees an auditable, single source of truth for external access.	• Deviation: Abandons the "single IAM tool for everything" concept by establishing a specialized B2B boundary separate from the internal SailPoint platform.	Strong Alignment. The architectural deviation of a dual-platform model is a strategic necessity to achieve enterprise-grade B2B security and scalability.

Option B

Decision Parameter	Pros	Cons	Overall Assessment
Feasibility & Functional Fit	• High functional maturity. • Natively handles provisioning, governance, and access workflows. • Out-of-the-box connectors for SAP IAS and Salesforce exist.	• Feasibility drops when factoring in the required niche SailPoint engineering skills to map complex B2B logic.	Moderate. Functionally feasible on paper, but practically hampered by the need for highly specialized configuration outside the organization's core skill set.
Complexity (Architecture & Integration)	• Standard vendor connectors provide a baseline starting point.	• Introduces a dual-platform IAM landscape alongside Entra. • Tri-vendor dependency (SailPoint, SAP, Salesforce) for API updates and patching.	High Complexity. Increases architectural debt and fragments the identity ecosystem, preventing a unified security posture.
Cost & Effort to Implement	• Prevents the need for ground-up custom connector coding.	• High upfront licensing costs for external users. • Premium rates for specialized SailPoint implementation engineers. • High opportunity cost (diverting funds from the strategic Microsoft roadmap).	High Cost/Effort. Difficult to justify the capital expenditure when the organization is already heavily invested in Microsoft entitlements.
Ongoing Operational Impact & Cost	• Strong audit logging and compliance reporting capabilities.	• Creates operational silos; requires maintaining two sets of administrative expertise. • Forfeits native consolidation benefits of the Microsoft stack (e.g., shared telemetry, unified Conditional Access).	High Negative Impact. Splitting internal (Entra) and external (SailPoint) identities prevents a single-pane-of-glass view of enterprise access and risk.
Program Principles & Deviations	• Meets baseline security and governance compliance principles.	• Major Deviation: Directly contradicts the established strategic principle of utilizing Microsoft Entra as the primary identity provider. • Violates consolidation and simplification principles.	Critical Failure. Selecting SailPoint actively works against the organization's stated architectural direction and cloud strategy.

Option C

Critical Failure. Exposes the organization to unacceptable levels of unmonitored risk and regulatory non-compliance

Decision Parameter	Pros	Cons	Overall Assessment
Feasibility & Functional Fit	• Represents the current, known operational state.	• Functionally fails to meet modern standards for identity lifecycle management. • Highly error-prone and degrades data quality.		• Leverages existing SAP Cloud Identity Services APIs to automate provisioning from S/4HANA. • Utilizes native Salesforce tools (Flows, JIT) for automated B2B onboarding. • Empowers partners and customers via delegated administration and federated SSO across both platforms. • Leaves the architecture open for a future IGA retrofit without vendor lock-in today.	• Lacks centralized cross-system lifecycle management. • Relies heavily on external admins to promptly deprovision users in both systems, which can lead to lingering active accounts across the digital estate.	High (Locally). Functionally excellent for immediate onboarding needs and external self-service across both SAP and Salesforce, though it entirely lacks an enterprise-wide governance layerLow. The model has exhausted its practical limits and cannot support current or future business scale.
Complexity (Architecture & Integration)	• No new technical integrations or architectural changes required.	• Operationally complex. • Impossible to establish a "single pane of glass" to correlate identities or investigate cross-platform lateral movement.	High Operational Complexity. The architecture is technically simple but creates a highly fragmented and opaque operational environment.	Capitalizes on successful API integrations and native platform capabilities rather than requiring a net-new enterprise architecture. • Defers the complex design decisions and heavy lift of deploying a full centralized governance platform.	• Fragmented architecture means a "single pane of glass" for identity visibility does not exist natively. • Retrofitting an IGA later will require mapping delegated permissions and normalizing data across two distinct, highly customized silos.	Moderate. Technical complexity is effectively contained to platform-specific workflows, keeping the overarching architecture lean, though cross-system governance remains a manual challenge.
Cost & Effort to Implement	• Maximizes ROI on recent SAP integration work and existing Salesforce licenses. • Avoids significant upfront licensing, deployment costs, and organizational change management associated with a new governance tool.	• Requires upfront configuration effort to build and test Salesforce automations. • Gathering cross-system audit evidence remains a labor-intensive manual effort. • Future IGA integration will carry compounded data consolidation costs.	Cost-Effective (Short-Term). Highly efficient use of current investments, delivering immediate value to both SAP and Salesforce workflows while deferring overarching governance expenses	Cost & Effort to Implement	• $0 upfront capital cost. • Zero implementation effort.	• Massive hidden operational costs absorbed by helpdesk and skilled administrators. • High potential cost of a security breach stemming from orphaned accounts.	False Economy. Avoids implementation costs but guarantees escalating day-to-day operational burn and risk exposure.
Ongoing Operational Impact & Cost	• None (maintains current state).	• Severe administrative bottlenecks. • Constant manual gathering of disjointed evidence for audits. • Degraded external user experience.	Severe Negative Impact. Manual management drains resources and damages the organization's professional image with external partners.	Program Principles & Deviations	• None.	• Major Deviation: Violates core principles of security (least privilege, automated deprovisioning), governance, and consolidation. • Fails to leverage centralized identity controls.	Drastically reduces internal IT workloads across both SAP and Salesforce through automated provisioning and delegated administration. • Significantly improves the external user experience via self-service and flexible authentication options.	• Internal compliance and security teams face a multiplied manual effort to audit the actions of external admins across two separate, disconnected systems.	Net Positive for IT Operations. Provides massive operational relief for internal identity and support teams, though it shifts a heavy, manual burden onto audit and compliance functions.
Program Principles & Deviations	• Strongly aligns with principles of automation, self-service, and process efficiency within the local ecosystems. • Retains strategic flexibility for future platform decisions.	• Deviation: Departs from the principle of centralized governance and unified visibility. • Security posture (MFA, session policies) must be manually dual-maintained across independent platforms.	Partial Alignment. Successfully achieves local automation and operational efficiency, but defers holistic enterprise identity consolidation and oversight.

See also

Change log