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: 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 your 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.

Constraints

While Microsoft Entra provides a robust foundation for external identity management, there are specific functional, operational, and commercial constraints that must be factored into the implementation plan.

1. Feature & Functional Constraints

• Custom Workflow Complexity: Entra’s native Entitlement Management and Lifecycle Workflows are highly effective for standard B2B scenarios. However, they are less flexible out-of-the-box than legacy, purpose-built IGA platforms when dealing with deeply nested, highly customized, or conditional approval hierarchies. Complex approval chains often require custom development using Azure Logic Apps extensions.

• SCIM Schema Limitations: Entra’s out-of-the-box user attribute mapping is bounded by standard SCIM schema constraints. If the business requires highly bespoke attribute transformations, advanced string manipulation, or data enrichment from third-party APIs mid-flight, this will require custom Azure Functions or middleware, adding development overhead.

• SAP Provisioning Architecture: Native Entra provisioning directly into SAP ERP (e.g., ABAP systems) is not supported. The integration must be mediated through SAP Cloud Identity Services (SAP IAS). While this is SAP's recommended architecture, it inherently introduces an additional identity broker into the provisioning pipeline, which must be monitored and maintained.

2. Operational & Organizational Constraints

• Dual-Platform Operations: Because internal identities are governed via SailPoint and external identities via Entra, the IT and IAM teams must operate a bifurcated governance model. This introduces operational overhead, requiring the team to maintain deep technical expertise across two distinct platforms and forcing audit teams to pull consolidated reports from two separate systems.

• BYOI Fallback Support: A core benefit of B2B collaboration is Bring Your Own Identity (BYOI). Contrary to previous assumptions, partners do not need a Microsoft environment to authenticate; Entra supports SAML/WS-Fed direct federation, Google federation, and Email One-Time Passcode (OTP). However, for partners utilizing OTP, the IT helpdesk may still incur a minor support burden assisting users who struggle with email-based authentication flows.

• Governance UI Limitations: Entra ID Governance administration is largely managed through the Entra admin center. There is currently no highly customizable, "low-code" governance portal designed specifically for non-technical business unit administrators, meaning complex access package creation generally remains an IT responsibility.

3. Licensing & Cost Constraints

• MAU Billing Variability: While cost-effective, the Monthly Active User (MAU) billing model for the Entra ID Governance for Guests add-on introduces month-to-month financial variability. Costs will fluctuate based on the actual number of guest users who trigger a billable governance event (like an access review) in a given month.

• Add-on Prerequisites: To utilize advanced lifecycle workflows and access reviews for external users, the tenant must be licensed for Entra ID P1 or P2, and the specific Governance add-on must be procured and linked to an active Azure subscription.

• Third-Party Support: Microsoft support covers the Entra platform itself but does not extend to troubleshooting the specific internal configurations of third-party applications (like SAP or Salesforce) connected to it. Specialized vendor support or professional services may be required for complex downstream application issues.

4. Integration & Platform Constraints

• Salesforce Profile Automation: Entra does provide a native, out-of-the-box SCIM connector for Salesforce. However, mapping Entra groups to complex Salesforce configurations (like assigning specific Salesforce community profiles, permission sets, or feature licenses) can be intricate. This often requires supplementary automation within Salesforce (e.g., Salesforce Flows) to catch the provisioned user and assign nuanced internal metadata.

• Legacy Protocol Support: Entra is optimized for modern authentication (SAML, OIDC, OAuth 2.0). If external users need to access legacy on-premises applications that rely strictly on LDAP or Kerberos, additional infrastructure such as Microsoft Entra Private Access or custom App Proxy configurations will be required.

• Conditional Access Scope: Entra's Conditional Access policies are highly effective, and they do natively protect third-party SaaS applications like SAP and Salesforce, provided those applications use Entra as their federated Identity Provider (IdP).

However, the constraint lies in the fact that Entra cannot enforce session controls or risk-based policies if the external user circumvents Entra and logs into the target system directly via a local account (which violates the BYOI business rule established earlier).

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.

Options considered

Option A: 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 A

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 D: 

Evaluation

Option A

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 B

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.	Low. 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.
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.	Critical Failure. Exposes the organization to unacceptable levels of unmonitored risk and regulatory non-compliance.

See also

Change log