One?off partner sign?in setups drifted; Entra External ID access packages and Conditional Access standardized federation

Overview

An energy firm granted partners access through one?off Single Sign?On (SSO) setups per vendor. Each relationship meant a new SAML/OIDC configuration, custom claims, and manual deprovisioning when contracts ended. Approval trails were scattered, access lingered after partner staff changes, and recertifications were slow. Intelligex standardized federation using Microsoft Entra External ID for business?to?business collaboration, shifted partner onboarding to access packages with expirations, and enforced Conditional Access and access reviews. Bespoke integrations declined, partner onboarding moved faster, and access recertification became reliable—while existing identity, IT Service Management (ITSM), and application stacks stayed in place.

Client Profile

• Industry: Energy (generation, trading, and field services)
• Company size (range): Global business units with joint ventures and a large vendor ecosystem
• Stage: Mix of cloud and on?premises apps; custom SSO per partner and app; inconsistent MFA and recertification; manual offboarding on contract end
• Department owner: IT & Infrastructure (Identity & Access Management)
• Other stakeholders: Security, Procurement/Vendor Management, Legal/Privacy, Application Owners, Business Unit Leads, Internal Audit, Service Desk

The Challenge

Every partner brought different identity requirements. Some offered their own identity providers, others asked for accounts in the firm’s directory, and some used shared credentials. SSO configurations were built case by case with custom claims and attribute mappings. MFA policies varied by application, and partner account lifecycles were managed via tickets or email. When contracts changed or vendors swapped people on a project, access drifted and approvals were hard to trace to policy.

Onboarding took longer than it needed to. App owners asked Identity for a new connection, Vendor Management negotiated access terms, Security requested MFA and sign?in restrictions, and Legal checked data handling clauses. The result was a proliferation of unique SSO setups that were difficult to support. Access recertifications were run as campaigns with spreadsheets and screenshots, not as part of a routine lifecycle tied to sponsorship, expiration, and application context.

Deprovisioning was uneven. Partner users retained access beyond project end dates, parallel approvals created blind spots, and stale guest accounts accumulated. Audit requests for who approved access, under what policy, and when it was last reviewed required assembling evidence across systems and email chains.

Why It Was Happening

Root causes were a bespoke federation model and a missing, governed partner lifecycle. Each engagement translated into a new SAML/OIDC configuration with unique claims and provisioning steps. There was no standard definition of partner entitlements per application, no access packages with expirations, and no automated reviews tied to sponsors. Group membership granted access indefinitely, and recertifications were event?driven rather than continuous.

Ownership and timing were split. Application teams needed external users quickly, Procurement and Legal required controls and terms, and Identity enforced technical policy. Without a shared control plane that combined federation, approval, expiration, and review, the default was to treat every vendor as an exception.

The Solution

Intelligex standardized partner access through Microsoft Entra External ID and Identity Governance. Federation moved to a single model for business?to?business collaboration; partner users were invited or collaborated cross?tenant; and access was granted via entitlement management with approvals, expirations, and automatic renewals. Conditional Access enforced MFA and session controls by app. Periodic access reviews validated ongoing need, and stale access was removed automatically. The design aligned to Microsoft guidance for Microsoft Entra External ID, Entitlement Management, and Access Reviews, with per?app policies in Conditional Access.

• Integrations: Microsoft Entra External ID for partner federation and invitations; Entitlement Management for access packages and approvals; Access Reviews for recertification; Conditional Access for MFA and session controls; cross?tenant access settings for trusted partners; ITSM for request tracking and notifications; application SAML/OIDC connectors from the app gallery and custom non?gallery apps.
• Canonical partner model: Partner directory entries with organization, contract or statement of work, sponsor, apps/groups, expiration date, and data sensitivity; dynamic groups for app role assignments.
• Policies and guardrails: Standard MFA for partner sign?ins; terms of use acknowledgments; session lifetime and location restrictions per app class; approval tiers by sensitivity (business owner, security, legal where required).
• Access packages: Bundled app and group assignments with sponsor, justification, expiration, and renewal rules; separate packages for project, vendor, and joint venture scenarios.
• Approvals and evidence: Maker?checker approvals for sensitive apps; ITSM tickets linked to package and policy versions; exportable records for audit with approver and sponsor context.
• Reviews and cleanup: Scheduled access reviews by sponsor and app owner; auto?remove on no?response; guest lifecycle tasks for orphaned accounts; re?invite flow for partners with ongoing agreements.
• Security and privacy: Role?based administration; least?privilege group design; minimal claims shared cross?tenant; logging to the SIEM; data residency aligned with policy.

Implementation

• Discovery: Cataloged current partner connections, SAML/OIDC claims, and app dependencies; inventoried partner user stores and onboarding paths; reviewed MFA and session policies; gathered contract and legal requirements; sampled recent audits and recertification processes.
• Design: Defined the partner directory schema (organization, sponsor, expiration); authored access packages per app class and business scenario; mapped approval flows and exception tiers; set Conditional Access baselines; planned cross?tenant access settings for trusted partners; specified dashboards and evidence exports.
• Build: Configured Entra External ID for B2B collaboration and invitations; created access packages with approval policies and expirations; enabled access reviews by app and sponsor; applied Conditional Access templates; migrated priority apps to standardized SAML/OIDC connectors; integrated ITSM for request intake and notifications; enabled logging and dashboards.
• Testing/QA: Ran pilots with selected vendors and joint venture partners; validated invitation, sign?in, MFA, and access package assignment; rehearsed expiration and renewal flows; tested access reviews with sponsors; verified deprovisioning behavior on contract end; tuned policies based on edge cases.
• Rollout: Onboarded high?value apps and partners first; redirected new requests to access packages; phased legacy custom SSO connections into the model during maintenance windows; kept legacy paths as a controlled fallback until adoption stabilized.
• Training/hand?off: Delivered sessions for Application Owners, Vendor Management, and Service Desk on invitations, packages, approvals, and reviews; published sponsor guides for approving and certifying access; updated SOPs for partner onboarding/offboarding; transferred ownership of policies and dashboards to Identity & Access Management under change control.
• Human?in?the?loop review: Established a governance forum for exception requests, policy updates, and review outcomes; decisions recorded with rationale and effective dates; improvements fed back into packages and Conditional Access templates.

Results

Partner access stopped being a one?off integration problem. Application owners published standardized SAML/OIDC connectors, sponsors granted access via packages with clear expirations, and partner users signed in with predictable MFA and session controls. When projects ended, access expired on schedule or was renewed with justification, and stale guest accounts were cleaned up as part of the same lifecycle.

Recertification and audit moved from campaigns to routine governance. Sponsors and app owners completed periodic access reviews with focused lists, approvals and denials were logged against policies, and auditors saw consistent evidence for who approved access and when it was last validated. Identity, ITSM, and applications remained; the change was a federation and governance layer that turned partner access into a standard service.

What Changed for the Team

• Before: Each vendor needed a custom SSO and claims mapping. After: Partners used a standard Entra External ID model with gallery connectors and common claims.
• Before: Access lingered after project end. After: Access packages carried expirations and renewal rules tied to sponsors.
• Before: MFA and session rules varied by app. After: Conditional Access enforced consistent controls by app class.
• Before: Recertifications ran as spreadsheets and emails. After: Scheduled access reviews removed or renewed access with evidence.
• Before: Approvals lived in inboxes. After: Approvals and exceptions were recorded in packages and ITSM with links to policies.
• Before: Offboarding and cleanup were manual. After: Guest lifecycle tasks and auto?remove kept directories tidy.

Key Takeaways

• Standardize federation; use a single B2B model instead of custom SSO per partner.
• Bundle access; access packages with expirations and approvals reduce drift.
• Enforce policy at sign?in; Conditional Access aligns MFA and session controls across apps.
• Recertify on a schedule; access reviews keep partner access current without campaigns.
• Design for sponsors; make business owners accountable for approvals and reviews.
• Integrate, don’t replace; keep identity, ITSM, and apps—add a governance layer around partner access.

FAQ

What tools did this integrate with? Partner federation and invitations used Microsoft Entra External ID. Entitlement management and access reviews came from Microsoft Entra Identity Governance (Entitlement Management, Access Reviews). Per?app sign?in policy used Conditional Access. Requests and notifications flowed through the firm’s ITSM, and application SSO relied on gallery and custom SAML/OIDC connectors.

How did you handle quality control and governance? Access packages and Conditional Access templates were versioned with owners and rationale. Sensitive apps required maker?checker approvals and shorter expirations. Access reviews ran on a schedule with auto?remove for non?responses. All invitations, approvals, policy changes, and review outcomes were logged and exportable for audit.

How did you roll this out without disruption? The team piloted with a few partners and high?value apps, validated invitations, sign?ins, and expirations, and kept legacy SSO connections as a controlled fallback. New partner requests were routed to access packages first. Legacy integrations migrated during maintenance windows, and policies were tuned based on early review outcomes.

How did you manage MFA and device requirements for partners? Conditional Access enforced MFA by default for partner sign?ins. For apps requiring stronger signals, session policies and location restrictions applied. Device compliance checks were scoped based on data sensitivity, balancing partner diversity with risk controls.

What about joint ventures and long?term vendors? Joint ventures used cross?tenant access settings to trust specific partner tenants, reducing friction while keeping policy intact. Long?term vendors received packages with longer renewals but the same review cadence, sponsor accountability, and expiration behavior.

How were exceptions and urgent access handled? Exception requests flowed through ITSM with reason codes and compensating controls. Temporary access packages granted limited scope with short expirations. Emergency access followed the documented path and was reviewed at the next governance meeting.

How did you clean up existing guest accounts? A guest lifecycle task identified orphaned guests by sponsor and last activity. Sponsors reviewed lists, and unused accounts were removed or re?invited via packages. Cleanup results and rationale were logged for audit.