Issue

Problem Statement

The organization 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 urgently requires a centralized, purpose-built platform to manage a rapidly growing footprint of over 30,000 external identities. Currently, Syensqo lack a scalable solution capable of efficiently handling the lifecycle, governance, and seamless authentication of this volume of external partners, vendors, and clients.

Why a Decision is Required

A formal architectural decision is required to select and adopt a new 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.

Business and Technical Problems Addressed

This decision will directly address the following critical gaps:

• Scale and Performance: 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:  Implementation to Microsoft Entra (specifically utilizing Entra External ID and Entra ID Governance).

Strategic Rationale For an organization committed to a Microsoft-first technology strategy, maintaining a disparate third-party identity platform like SailPoint for B2B users creates unnecessary architectural complexity, licensing overlap, and integration overhead. Adopting Microsoft Entra as Syensqo's unified identity control plane is the most logical and future-proof path to manage the 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 identity and access management directly within the Azure fabric Syensqo already own's and operates. This inherently reduces technical debt and eliminates the need to build and maintain custom connectors. Crucially, it allows the organization to govern external partner access using the exact same enterprise security framework (e.g., Conditional Access, continuous threat monitoring, Zero Trust policies) that currently protects Syensqo's 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 Syensqo's core employee directory remains unpolluted. Furthermore, it shifts the massive operational burden away from internal IT through a "Bring Your Own Identity" (BYOI) model—allowing external users to securely authenticate using their own organization's credentials—while Entra ID Governance natively automates the onboarding, access review, and offboarding lifecycle.

3. Frictionless Enterprise SaaS Integration (SAP & Salesforce) - While 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 (SAML, OIDC, SCIM) to ensure that when an external identity is approved or terminated in Azure, their access is automatically provisioned or revoked downstream in SAP and Salesforce, guaranteeing a single 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

• Technology & Architecture

  • Syensqo is committed to a long-term Microsoft-first cloud strategy with Azure as the primary cloud platform and Microsoft 365 as the foundation for employee productivity.
  • Microsoft Entra External ID will remain the strategic platform for B2B identity management throughout the planning horizon (minimum 3–5 years), with no material shifts anticipated in Microsoft's roadmap for external identity capabilities.
  • Azure remains operationally and financially viable as the organization's primary cloud platform; no material shift to multi-cloud or alternative cloud providers is anticipated.
  • Microsoft Entra ID Governance licensing and capabilities will continue to be available and supported; no significant licensing model changes are anticipated.
  • Open identity standards (SAML 2.0, OIDC, SCIM) will continue to be the primary integration mechanism across SAP, Salesforce, and other enterprise SaaS platforms.
  • Azure infrastructure and managed services (App Service, Function Apps, etc.) will remain available at current or competitive pricing.

  Organizational & Operational

  • The organization will establish and fund a dedicated Cloud Identity team with expertise in Microsoft Entra, SCIM provisioning, and enterprise identity architecture; existing SailPoint expertise will be re-allocated or phased out.
  • Business stakeholders will accept and adopt a 'Bring Your Own Identity' (BYOI) model for external users, requiring cultural shift and change management; legacy password-based authentication for external users will be deprecated.
  • External user onboarding and offboarding processes will be re-engineered to align with Entra's lifecycle workflows and governance models; business units will adopt standardized processes rather than custom workarounds.
  • Regulatory and compliance frameworks (GDPR, SOC 2, industry-specific certifications) will remain stable; no material new compliance requirements are anticipated that would invalidate Entra's suitability.

  Financial & Commercial

  • Microsoft Entra ID Governance licensing costs will remain within acceptable bounds; no material price increases beyond standard annual inflation are anticipated.
  • SailPoint contract terms permit exit without material financial penalty or can be renegotiated; license sunk costs are accepted as a migration expense.
  • Internal IT and security teams will accept the operational cost of managing a separate external identity platform alongside the internal employee identity system (dual management model) as a strategic necessity.
  • The organization has sufficient capital and operational budget to fund both the migration program and ongoing operational overhead for the planned 5-year period.

  Risk & Compliance

  • Microsoft Entra External ID meets all applicable data residency, sovereignty, and regulatory requirements (e.g., GDPR, CCPA, industry-specific data protection mandates) for all geographies in which Syensqo operates.
  • No material regulatory changes that would materially restrict or prohibit cloud-based B2B identity management are anticipated during the planning horizon.
  • Microsoft Entra's security posture, threat detection, and compliance certifications will remain at or above industry standards and will satisfy audit and compliance requirements.

Constraints

Feature & Functional Constraints

• Microsoft Entra External ID is optimized for cloud-native B2B scenarios and OAuth/OIDC flows. Organizations with significant on-premises applications requiring LDAP or proprietary authentication protocols may require additional middleware or custom connectors, increasing complexity and maintenance burden.
• Entra's access lifecycle workflows, while comprehensive, are less flexible than purpose-built IAM platforms for highly customized, business-process-specific approval hierarchies or conditional access rules. Complex approval chains involving external approvers or multi-stage hierarchical reviews may require custom Logic App extensions.
• Entra's out-of-the-box user attribute mapping and provisioning is constrained by SCIM schema limitations. Organizations requiring bespoke user attribute transformations or tenant-specific data enrichment may incur development overhead.
• Entra's native integration with SAP is mediated through SAP Cloud Identity Services; direct, native integration with SAP ERP is not available. This introduces an additional identity broker in the architecture, adding complexity to the provisioning pipeline.

Operational & Organizational Constraints

• Entra's governance capabilities require adoption of a dual-identity-platform model: internal employees remain managed via Entra (core), while external identities are managed via Entra External ID. This introduces operational overhead and requires distinct team expertise.
• Organizations cannot consolidate internal and external user directories into a single Entra directory without material security and data governance implications. A separate, dedicated directory for external identities is a mandatory architectural constraint.
• Entra ID Governance's access review and attestation workflows rely heavily on business rule configuration and custom extensions; there is no 'low-code' UI for complex governance scenarios, limiting self-service capability for business unit admins.
• Bring Your Own Identity (BYOI) models require that external organizations maintain active Azure AD or Microsoft Account infrastructure. External partners without existing Microsoft identity infrastructure will require credential issuance, creating a support burden.

Licensing & Cost Constraints

• Microsoft Entra ID Governance licensing is consumed on a Monthly Active User (MAU) basis for guest users. Organizations with highly volatile external user populations (frequent additions/removals) may experience unpredictable monthly costs.
• Premium Entra features (advanced access reviews, lifecycle workflows, custom extensions) require Microsoft Entra Suite or standalone Entra ID Governance licenses at tier-2 or tier-3 pricing, limiting the ability to manage large external populations cost-effectively.
• Entra licensing does not include dedicated support for third-party application connectors (e.g., custom SAP or Salesforce integrations); professional services or custom development may be required, incurring additional cost.

Integration & Platform Constraints

• Salesforce integration relies on SAML or OIDC via Entra; Salesforce does not natively support SCIM-based user provisioning to the standard Salesforce org. Attribute synchronization and user lifecycle updates may require manual configuration or custom Salesforce automation.
• SAP integration is achieved via SAP Cloud Identity Services as an intermediary. Direct, real-time provisioning updates from Entra to on-premises SAP systems (e.g., SAP ERP running on-premises) may require additional middleware or API gateways.
• Entra's conditional access policies are limited to Azure/Microsoft 365 environments; enforcing conditional access rules on external user access to third-party SaaS applications (SAP, Salesforce) requires additional third-party solutions or custom integrations.

Impacts

Identity Architecture & Infrastructure

• Entra Directory Structure: A dedicated, separate Microsoft Entra directory will be created for external identities, isolated from the employee directory. This creates a clear security boundary but requires dual directory management and governance.
• Provisioning Pipelines: SAP and Salesforce provisioning workflows must be re-architected to consume identity and access data from Entra External ID via SCIM provisioning agents and API connectors. Existing SailPoint connectors will be deprecated and decommissioned.
• On-Premises Identity Sync: Any on-premises AD/LDAP systems currently synchronized with SailPoint will require re-architecture or consolidation; hybrid identity scenarios must be carefully planned to avoid directory pollution.

SAP Ecosystem Impact

• SAP User Provisioning: All external user provisioning to SAP systems (including User Master, role assignments, and system access) must be re-routed through Entra → SAP Cloud Identity Services → SAP. This introduces a new intermediary in the provisioning chain.
• SAP Access Reviews & Governance: Attestation workflows for SAP user access must be integrated with Entra ID Governance access reviews; existing SailPoint audit logs will no longer be authoritative.
• SAP Compliance & Audit: SAP audit trails, system logs, and compliance reports must be reconfigured to reflect identity changes sourced from Entra External ID rather than SailPoint. Audit trail continuity across the migration must be carefully managed.
• SAP On-Premises vs. Cloud: If Syensqo operates both on-premises SAP ERP and cloud-based SAP solutions (e.g., SAP SuccessFactors, SAP Analytics Cloud), provisioning strategies may differ; each platform must be evaluated individually for Entra integration maturity.

Salesforce Ecosystem Impact

• Salesforce User Provisioning: External user provisioning to Salesforce orgs must be implemented via SAML/OIDC SSO and custom Salesforce automation (e.g., workflows, Flows) to handle user lifecycle events (create, update, deactivate). Native SCIM support is limited.
• Salesforce License Consumption: External user access to Salesforce may consume Salesforce licenses (e.g., Partner Community, Customer Community licenses) depending on the use case; license planning and cost optimization are critical.
• Salesforce Metadata & Config: Entra attribute mappings must align with Salesforce user attributes (e.g., custom fields, profile assignments); any mismatch will require custom Salesforce development or middleware transformation logic.

Data Migration & Cutover

• Legacy External User Data: All historical external user records, attributes, and access assignments currently stored in SailPoint must be extracted, transformed, and migrated to Entra External ID. Data cleansing and validation are critical to prevent access control errors.
• Access Rights Migration: All existing access package assignments, group memberships, and role assignments for external users must be re-created in Entra; this is a manual, time-intensive effort if not fully automated.
• Historical Audit Trail: SailPoint audit logs and historical identity change records must be preserved for compliance and forensic purposes; this data may need to be exported and archived separately.

Organizational & Governance

• Identity Governance Team: Existing SailPoint-focused identity team members must upskill on Entra External ID, SCIM provisioning, and lifecycle workflows. SailPoint expertise will become obsolete.
• Business Process Re-engineering: External user onboarding workflows (e.g., HR systems, vendor management platforms) must be re-engineered to trigger Entra provisioning actions; current SailPoint integrations will be deprecated.
• Change Management: External partners and employees must be informed of and trained on new authentication methods (e.g., BYOI, MFA); legacy password-based access will be phased out.
• Governance Council: Entra-specific governance decisions (e.g., access review cadence, approval hierarchies, external sponsorship models) must be established and communicated to business stakeholders.

Security & Compliance

• Conditional Access: New Conditional Access policies must be designed and deployed to enforce Zero Trust principles for external users (e.g., device compliance, location-based restrictions, risk-based adaptive auth).
• Audit & Logging: All Entra identity events, provisioning actions, and access reviews must be logged to Azure Log Analytics and integrated with SIEM/security monitoring platforms. Existing SailPoint SIEM integrations must be replaced.
• Compliance Attestation: Audit and compliance teams must validate that Entra External ID meets all applicable regulatory requirements (GDPR, SOC 2, industry-specific mandates) in all operating regions.

In-Flight Projects & Dependencies

• Any active projects involving identity management, access control, or provisioning changes must be assessed for impact and either aligned with the Entra migration or deferred until post-migration.
• Planned cloud migrations or SAP/Salesforce upgrades should be sequenced carefully to avoid collision with the Entra deployment; careful project roadmap alignment is required.

Financial Impact

Implementation Costs

The primary implementation costs associated with this decision fall into three categories. First, professional services and internal effort required to design, configure, and deploy the Entra External ID and Entra ID Governance environment — including tenant configuration, Conditional Access policy design, access package and catalog structure, lifecycle workflow development, and the build-out of SCIM-based provisioning flows to SAP and Salesforce. Second, the data cleansing and migration effort to extract external identities from SailPoint, remediate data quality issues, and onboard those identities into Entra with correctly mapped attributes, entitlements, and governance policies. Third, upskilling and training costs for the IAM team and broader IT operations staff who must develop competency in Entra ID Governance administration alongside their existing SailPoint expertise.

Licensing and Subscription Costs

The ongoing licensing model introduces a shift in cost structure. Internal employee governance remains on existing SailPoint licensing, which is unaffected. For external identities, Syensqo must maintain the prerequisite Microsoft Entra ID P1 or P2 subscription at the tenant level, the Entra ID Governance product subscription, and — critically — the Microsoft Entra ID Governance for Guests add-on, which operates on a consumption-based Monthly Active User (MAU) billing model rather than a fixed per-seat cost. This means the external identity governance cost will fluctuate month to month based on the number of guest users actively triggering billable governance events. While this model can be cost-efficient during periods of low activity, it introduces a degree of financial variability that must be monitored and forecasted, particularly as the external identity population grows beyond the current 30,000 baseline. An Azure subscription must also be linked to the tenant to enable guest billing.

Operational Costs

On an ongoing basis, Syensqo will bear the operational cost of managing a dual-platform identity governance model — SailPoint for internal and Entra for external. This includes the administrative overhead of maintaining two sets of operational procedures, two sets of integrations into downstream systems like SAP and Salesforce, and consolidated reporting across both platforms for audit and compliance purposes. However, this is partially offset by the reduction in operational burden that Entra's self-service and automation capabilities introduce — particularly the BYOI model, automated lifecycle workflows, and delegated access package management, all of which reduce the manual effort currently required to manage external identities.

Cost Offsets and Efficiencies

The decision is expected to deliver cost efficiencies over time by eliminating the need for custom-built connectors and manual processes that currently support external identity management within SailPoint. The native alignment with Syensqo's existing Microsoft investment reduces integration overhead and avoids the licensing overlap of maintaining a third-party platform for a function that can be delivered within the incumbent ecosystem. The extent of these savings will depend on the volume and complexity of external identity operations that are successfully automated through Entra's governance capabilities.

Business Rules

Business Rules

The following business rules are derived from this decision and must be enforced through platform configuration, policy, and operational procedure.

Identity Platform Segregation

All external (B2B) identities — including partners, vendors, clients, and any non-employee entity — must be created, managed, and governed exclusively within Microsoft Entra External ID. No new external identity may be provisioned within SailPoint. SailPoint remains the sole governance platform for internal (employee) identities. An identity cannot be governed by both platforms simultaneously.

Guest User Type Classification

Every external identity onboarded into the Entra tenant must be assigned a userType of Guest. Under no circumstances may an external user be provisioned as a Member within the core employee directory. This classification is non-negotiable and underpins both the architectural segregation model and the guest billing mechanism.

Access Must Be Package-Based

Access to downstream systems — including SAP, Salesforce, Microsoft 365 resources, and any other integrated application — must not be granted to external users on an ad hoc or manual basis. All external user access must be assigned through a defined Entra ID Governance access package with an associated policy that specifies approval requirements, duration, and review cadence. Direct role or group assignment outside of the access package model is not permitted for external identities.

Bring Your Own Identity as Default Authentication

External users must authenticate using their own organization's identity provider wherever possible under the BYOI model. Federated authentication via SAML 2.0 or OIDC is the preferred and default method. Email one-time passcode or local account authentication may only be used as a fallback for partners who do not operate a compatible identity provider, and this exception must be documented and reviewed periodically.

Sponsorship and Approval Required for Onboarding

No external identity may be onboarded without a designated internal sponsor. Every access package policy for external users must include at least one approval stage with a named sponsor or delegated approver from the relevant business unit. Self-approval by the requesting external user is not permitted.

Time-Bound Access with Mandatory Review

All access granted to external identities must be time-bound. Open-ended or permanent access assignments are not permitted for B2B users. Every access package assignment must carry a defined expiry period, and recurring access reviews must be configured to ensure that continued access is re-certified by the appropriate business owner or sponsor at a defined cadence. Failure to complete a review within the defined window must result in automatic revocation of access.

Automated Lifecycle Enforcement

External identity lifecycle events — onboarding, access modification, and offboarding — must be managed through Entra ID Governance lifecycle workflows and entitlement management policies, not through manual administrative action. When an external user's engagement with Syensqo ends or their access package assignment expires without renewal, their access to all downstream systems must be automatically revoked and their guest account must be disabled or removed in accordance with the defined offboarding workflow.

Provisioning and Deprovisioning Must Be Automated

The provisioning and deprovisioning of external user accounts in downstream systems — specifically SAP (via SAP Cloud Identity Services) and Salesforce (via the SCIM connector) — must be automated through Entra. Manual creation or removal of external user accounts directly within SAP or Salesforce is not permitted. The Entra directory must remain the single source of truth for external identity status, and downstream systems must reflect changes propagated from Entra.

No Governance Without Billing Enablement

The Microsoft Entra ID Governance for Guests add-on must remain enabled and linked to an active Azure subscription at all times. Governance features for external users — including access reviews, entitlement management policies scoped to guests, and lifecycle workflows — are non-functional without this billing linkage. Allowing the add-on to lapse or become disconnected is treated as a critical operational failure.

Consolidated Audit and Compliance Reporting

Identity governance evidence for audit and regulatory purposes must be producible from both SailPoint (for internal identities) and Entra (for external identities). A consolidated reporting mechanism or process must be established and maintained to ensure that auditors receive a complete and coherent view of Syensqo's identity governance posture without requiring independent interrogation of each platform.

Data Quality Standards for External Identities

External identity records in Entra must meet defined minimum data quality standards before being granted access to any downstream system. At a minimum, each record must include a verified external email address, a mapped organizational affiliation, a designated internal sponsor, and correctly populated attributes required for downstream provisioning. Records that do not meet these standards must be quarantined and remediated before access is provisioned.

Options considered

Option A: Use SailPoint to Manage All External Identities

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

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

However, functional capability alone does not make SailPoint the right choice for this use case. Several material factors weigh against this option, and when considered together, they present a compelling case for looking elsewhere.

Functional Assessment

SailPoint can technically 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 would make SailPoint a credible candidate. The challenge lies not in what SailPoint can do, but in whether it is the right platform for the organisation to invest in for this purpose.

Strategic Misalignment

SailPoint is not positioned as the strategic IAM solution for this organisation. 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 organisation’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 would mean committing further budget, skills, and operational capacity to a platform that the organisation is not investing in for the long term. Every pound spent on SailPoint licensing, custom development, and specialist resources is a pound not invested in the platform that will form the backbone of the organisation’s identity architecture going forward.

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 two sets of operational expertise, and fragments the identity management story across the enterprise.

Custom Connector Requirements

A significant practical concern is connector availability. While SailPoint offers a broad library of out-of-the-box connectors, the specific integration requirements for managing external identities within SAP IAS and Salesforce external-facing configurations may not be fully met by standard connectors.

In all likelihood, custom connectors will need to be developed to support the following:

• SAP IAS external identity provisioning. The standard SAP connector in SailPoint is designed around SAP on-premise user management (SU01, UME) and may not natively support the SAP IAS cloud identity service for external user scenarios. A custom or heavily customised connector would be required to provision, update, and deprovision supplier identities in SAP IAS.
• Salesforce external community users. While SailPoint has a Salesforce connector, managing external community or Experience Cloud users — as opposed to internal Salesforce CRM users — often requires additional configuration, custom attribute mapping, and profile/permission-set assignment logic that goes beyond the standard connector’s capabilities.

Custom connector development introduces several risks:

• Development cost and lead time. Building, testing, and certifying custom connectors requires specialist SailPoint development skills and adds significant delivery time to the programme.
• Ongoing maintenance burden. Custom connectors must be maintained as target systems evolve. SAP IAS and Salesforce both release regular updates that may break custom integrations, requiring reactive development effort.
• Talent dependency. SailPoint connector development is a niche skill set. The organisation would need to retain or contract these skills on an ongoing basis, adding to the total cost of ownership.

Ecosystem and Vendor Alignment

The organisation is a Microsoft-heavy environment. The technology estate is 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 identity platform that does not benefit from the native integration, shared security context, and unified management plane that the Microsoft ecosystem provides.

By contrast, Microsoft Entra External ID is purpose-built for external identity scenarios and is natively integrated with the same platform that manages internal identities, Conditional Access policies, security monitoring, and compliance tooling. Selecting SailPoint would forgo these integration advantages.

Cost Considerations

The total cost of ownership for the SailPoint option extends well beyond licensing:

• SailPoint platform licensing (per-identity or subscription model).
• Custom connector development for SAP IAS and Salesforce external identity scenarios.
• Specialist SailPoint engineering and administration resources (internal or contracted).
• Ongoing connector maintenance and platform upgrades.
• Training and knowledge transfer for operational teams.
• 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 Microsoft Entra External ID — which benefits from existing Microsoft licensing agreements, native ecosystem integration, and a consumption-based pricing model — the SailPoint option is difficult to justify on financial grounds.

Summary Assessment: Option A

Conclusion: SailPoint is a capable identity governance platform and meets the functional requirements for external identity management. However, it is not the strategic IAM direction for this organisation, it will require custom connector development that adds cost and risk, and it introduces an unnecessary parallel identity ecosystem in what is otherwise a Microsoft-centric environment. The investment would be better directed toward the platform that the organisation has already committed to for the long term.

Option B: 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 (SAP IAS). B2B customer identities would continue to be managed independently and manually within Salesforce. No centralized identity platform would be introduced, and no cross-system automation or governance tooling would be implemented.

This option represents the status quo. While it requires no upfront capital investment and no 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.

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

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 impossible to correlate identities across systems.

• 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, whether through credential theft, social engineering, or misuse by a former partner. 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, industry standards, 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, tamper-evident 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. Access accumulates indefinitely.

• High Probability of Audit Findings: Internal and external 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 SAP IAS and Salesforce, 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 supplier and customer 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) enforcement 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 or lateral movement.

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, delaying time-to-value for new partners and projecting a disjointed organizational image.

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:

• IT administrator hours lost to routine account creation, modification, and deactivation.

• Helpdesk resources consumed by external user password resets and login troubleshooting.

• The massive opportunity cost of highly skilled SAP and Salesforce administrators performing manual data entry rather than executing higher-value platform optimizations.

Summary of Risks: Option B

Option C: Option Title

Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

Option D: Option Title

Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

Evaluation

Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.

	Option A	Option B	Option C	Option D
Criterion 1	Pro Con	Pro Pro	Pro Con	Pro Con
Criterion 2	Pro Con	Con	Pro Pro	Con Con
Criterion 3	Pro	Con	Con	Pro

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log