Enhancing Secure Collaboration Without Compromising Identity Integrity
A large energy sector business approached us with a very familiar yet complex problem: they worked with a large number of subcontractors and partners, and needed to allocate actions to them in their HSE systems. Unfortunately, their internal IT infrastructure was configured so that only users from the company’s own domain could sign in directly. Allowing direct access to external companies, each with their own domain and identity management systems, was a non-starter due to stringent security policies. Any exception would require long approval processes and extensive risk assessments.
Without a proper multi-domain access strategy, operational teams resorted to unsafe workarounds: shared passwords, spreadsheets emailed between sites, and manual updates that bypassed central systems. All of these practices increased risk, both from a security perspective and in terms of HSE traceability and auditability.
Ultimately, the organisation adopted a hybrid approach: internal staff could authenticate using their own corporate domain (leveraging single sign-on (SSO) where possible), while contractors and partners were issued separate usernames and credentials to access shared platforms. This preserved domain security controls and kept security teams comfortable while still enabling cross-party collaboration.
Let’s unpack the deeper challenges around authentication in multi-domain scenarios, and some modern approaches being used to address them as part of an effective Information Security Policy
What Makes Multi-Domain Authentication So Hard?
Authentication is the process of proving who a user is before granting access to a system or resource. In single-domain environments, this is relatively straightforward: a directory such as Active Directory or an Identity Provider (IdP) contains the user’s credential and handles login requests. But once you span multiple domains, for example, when contractors use their own corporate directories or cloud identity providers, several technical and organisational issues emerge:
1. Identity Silos
Different organisations often run separate identity systems with different credential formats, password policies, and security controls. These identity silos don’t inherently trust one another, so a login accepted in one domain will not automatically grant access in another.
2. Lack of Shared Authentication Trust
If each domain has its own authentication logic, then there’s no easy way for one organisation to verify credentials from an external domain without federation or explicit trust agreements. Attempting to bypass this, for example, by copying identities into a central store, increases security risk and operational overhead.
3. Fragmented User Experience
Without shared authentication, users may need multiple credentials to access shared systems. This increases help-desk loads, causes frustration, and often leads to unsafe behaviour like repeated passwords or password sharing.
4. Operational Complexity and Compliance Risk
Managing different sets of credentials across domains makes it harder to enforce consistent policies like multifactor authentication (MFA), session timeouts, or risk-based access controls, all of which are essential for modern compliance and security.
Practical Architectural Approaches to Cross-Domain Authentication
There’s no one-size-fits-all solution, but several well-established and emerging technologies help organisations enable secure, scalable multi-domain access:
1. Federated Identity (SSO Across Domains)
Basically, federated identity means linking identities across systems so a user authenticated by one provider can be trusted by another. Common protocols include SAML 2.0, OAuth 2.0, and OpenID Connect (OIDC); standards that allow identity assertions to be passed securely between an identity provider (IdP) and a service provider (SP).
In this model, a contractor logs in with their own company’s identity platform; that provider issues a token that the client’s systems accept, essentially saying, “We’ve verified this user.” Federation can also support additional security layers like MFA and conditional access policies.
Federated SSO significantly improves the user experience, reduces password fatigue, and centralises trust, but it requires both parties to agree on protocols and trust frameworks.
2. Identity Brokers or Federation Hubs
In more complex ecosystems, organisations may rely on an identity broker, a system that sits between multiple identity providers and consolidates authentication flows. This architecture allows a platform to accept logins from various IdPs (internal, contractors’ systems, cloud directories) without tightly coupling systems together.
The broker translates between protocols and enforces consistent policies, reducing the burden on individual applications.
3. Third-Party IAM Platforms
Products such as ForgeRock/OpenAM, Okta, Azure AD External Identities, or similar IAM platforms provide multi-protocol support (including SSO, federation, adaptive risk scoring, and MFA) and act as a central authority for authentication across domains.
These platforms can abstract the complexity of each partner’s identity system, providing a unified interface for access control while respecting each organisation’s security posture.
4. Zero Trust and Adaptive Authentication
Instead of relying on static identity assertions, modern security architectures increasingly adopt zero trust principles, continuously validating identity and context. For example, a user’s authentication may be augmented with device posture checks, geolocation, or risk scores, making cross-domain access decisions more dynamic and secure.
This is especially useful when users are accessing from unmanaged devices or third-party networks.
5. Authentication Policy Silos for Internal Segmentation
Within Active Directory environments, authentication policy silos can isolate high-value accounts or services so that even authenticated users from one domain cannot access privileged resources unless authorised. These are particularly useful in hybrid domains or when tightly controlling privileged access is essential.
While not a direct solution for cross-partner access, policies like this illustrate the granular control organisations need when authentication crosses security boundaries.
Balancing Security and Usability
All of the above solutions involve trade-offs:
- Federation improves usability but requires agreed trust frameworks and can increase reliance on external IdPs.
- Central IAM platforms centralise control but can be costly and require careful policy planning.
- Zero trust approaches offer strong security but demand ongoing operational maturity.
The key is to choose an approach that aligns with the organisation’s risk tolerance, complexity of partner ecosystems, and compliance needs.
This diagram shows one possible approach using Microsoft Entra ID.
Conclusion: Bridging Silos With Secure Identity
The original Pisys case highlights a very real operational challenge: different organisations must work together efficiently without compromising security or forcing insecure workarounds.
Authentication and access management lie at the heart of this problem. Today’s solutions, from federation and identity brokers to cloud IAM platforms and zero trust models provide a path forward, allowing users from disparate domains to access shared systems securely and seamlessly. Making the right architectural and governance choices here doesn’t just improve digital collaboration, it strengthens the foundation on which organisational risk, compliance, and efficiency are built.
