Single Sign-On Implementation Guide for Businesses

Australian businesses are managing more applications than ever. The average organisation now runs over 370 SaaS tools alongside on-premise systems. Without a structured approach to identity, employees end up juggling eight to twelve separate logins every single day – and IT teams spend half their time resetting forgotten passwords.

Single Sign-On fixes this. But “just enabling SSO” is not a strategy. A poorly implemented SSO deployment can be more dangerous than having no centralised identity management at all – one compromised password could unlock every system in your business simultaneously.

This guide walks you through everything you need to plan, deploy, and secure SSO properly: how it works, which protocol to choose, how to integrate Microsoft Entra ID, how to pair it with MFA, and how to avoid the mistakes that lead to breaches. We also cover what Australian businesses specifically need to know about compliance under the ACSC Essential Eight and the Privacy Act.

At CodeHyper, we have helped businesses across Sydney implement identity and access management solutions that are secure, compliant, and built to scale. This guide reflects what actually works in practice.

What Is Single Sign-On (SSO)?

Single Sign-On is an authentication system that allows a user to log in once – with a single set of credentials – and gain access to multiple applications without being asked to authenticate again for each one.

When a user opens any connected application, that application checks for a valid session. If one exists, access is granted instantly. If not, the user is sent to the Identity Provider to log in. Once authenticated, a signed token is passed back to the application confirming the user’s identity and permissions. The user never sees this process – from their perspective, they just click and it opens.

This is meaningfully different from password managers or shared credentials. SSO centralises identity verification at a trusted system level, not the browser level. It is a proper architectural solution to a real security and productivity problem.

Why it matters for Australian businesses specifically: The ACSC recorded over 94,000 cybercrime reports in the 2023–24 financial year. Credential theft remains the leading entry vector. SSO, when paired with MFA, directly closes this gap – and it is directly referenced in the Essential Eight’s multi-factor authentication control. If your organisation is working toward Essential Eight compliance (or needs to for government contracts or cyber insurance), SSO is not optional.

How SSO Actually Works

Understanding the technical flow helps you make better decisions during implementation and troubleshoot issues when they arise.

Three parties are always involved in an SSO transaction:

The User (Principal): The person or system trying to access a resource – an employee, a contractor, or an API client.

The Identity Provider (IdP): The system that verifies identity. This is the authoritative source of truth for who a user is – examples include Microsoft Entra ID, Okta, and Google Workspace.

The Service Provider (SP): The application the user is trying to reach – Salesforce, SharePoint, your internal HR system, or any other tool.

The flow works like this:

The user tries to open a protected application. The Service Provider checks whether a valid session token exists. Finding none, it redirects the user to the Identity Provider. The IdP checks for an existing authenticated session. If the user has already logged in during this session, it skips re-authentication and issues a token immediately. If not, it presents the login screen.

After the user authenticates (and completes MFA if configured), the IdP creates a signed security assertion containing the user’s identity, attributes, and assigned permissions. It sends this assertion back to the Service Provider. The SP validates the assertion’s digital signature against the IdP’s public key. If everything checks out, access is granted with the correct role – no password entry required from the user’s perspective.

This session then persists across all connected applications until the session timeout expires or the user explicitly signs out. A properly configured Single Logout (SLO) ensures that signing out of one application ends the session across all connected systems simultaneously.

SSO Protocols: SAML vs OAuth 2.0 vs OpenID Connect

Choosing the wrong protocol for your environment is one of the most common – and most avoidable – SSO mistakes. Here is what each standard actually does and when to use it.

SAML 2.0

SAML (Security Assertion Markup Language) is the established enterprise standard, in widespread use since 2005. It uses XML-formatted assertions exchanged between the IdP and SP and is browser-based. SAML is the right choice for enterprise applications, government platforms, and legacy systems that explicitly require it. Most large organisations will have at least some SAML integrations in their environment, even if they are moving toward OIDC for new applications.

Use SAML when integrating with legacy ERP systems, older HR platforms, or any government-facing application that specifically requires SAML compliance.

OAuth 2.0

A common misconception: OAuth 2.0 is not an authentication protocol. It is an authorisation framework – it controls what a service is permitted to do on a user’s behalf, not who that user is. You will rarely deploy “OAuth SSO” directly; rather, OAuth 2.0 is the foundation that OpenID Connect is built on.

OpenID Connect (OIDC)

OIDC extends OAuth 2.0 with an identity layer, making it a true authentication protocol. It uses JSON Web Tokens (JWTs), which are lightweight and easy to work with in modern development environments. OIDC is the protocol of choice for Microsoft 365, Google Workspace, modern SaaS platforms, and any API-first or mobile application.

Use OIDC when integrating cloud-native applications, Microsoft services, or any environment where JSON and REST APIs are the standard.

The practical reality for most Australian SMBs: You will need to support both. SAML for any legacy or government-connected systems you still run. OIDC for your Microsoft 365 environment and modern SaaS stack. Document which protocol each application supports before you begin configuration – this audit will save you significant time later.

The Real Benefits of SSO for Australian Organisations

The business case for SSO is often framed around convenience. The more accurate framing is security and risk reduction.

Fewer credentials means fewer attack vectors. Password sprawl is one of the most stubborn security problems in enterprise IT. Employees reuse passwords across systems, choose weak ones for applications they consider unimportant, and write them down. SSO eliminates the proliferation of credentials – there is one password to protect, and it is protected by MFA.

Centralised security policy enforcement. With SSO, your security policies – MFA requirements, session lengths, access restrictions based on location or device – apply uniformly across every connected application. Without SSO, you are trying to enforce policy across dozens of separate systems with separate admin consoles and separate configurations.

Faster, more complete offboarding. When an employee leaves, disabling their account in the Identity Provider immediately revokes access to every connected application. Without SSO, offboarding requires manually removing the departing employee from every system – a process that frequently leaves orphaned accounts active for weeks or months. The ACSC identifies terminated employee account management as a material risk in Australian cyber incidents.

Significant IT overhead reduction. Password resets are consistently the highest-volume helpdesk request in most organisations. Gartner research places password-related requests at 20–50% of all helpdesk volume. SSO reduces this substantially. That time goes back to IT staff for higher-value work.

Compliance-ready audit trails. SSO consolidates authentication events into a single log stream. Instead of piecing together who accessed what from a dozen separate application logs, your security team has one source of truth. This is essential for incident investigation and for demonstrating compliance under the Privacy Act and Essential Eight.

Supports Zero Trust architecture. The Zero Trust security model – increasingly referenced in Australian government security frameworks – requires that every access request be verified before being trusted, regardless of network location. SSO with risk-based Conditional Access is a foundational component of Zero Trust identity strategy.

SSO with Microsoft Entra ID: What Australian Businesses Need to Know

For the majority of Australian SMBs and mid-market businesses already running Microsoft 365, Microsoft Entra ID (formerly Azure Active Directory) is the logical Identity Provider. It is already part of your Microsoft tenancy, natively integrates with the entire Microsoft ecosystem, and supports thousands of third-party SaaS applications through the Entra App Gallery.

For a foundational overview of the platform itself, see our guide to What Is Microsoft Entra ID and our deeper coverage of Entra ID Protection.

What Entra ID SSO covers out of the box:

All Microsoft 365 applications – Exchange, Teams, SharePoint, OneDrive, and the full suite – are authenticated through a single Entra ID sign-in. Users log in once and access everything without re-authenticating.

The Entra App Gallery includes pre-configured SSO connectors for over 3,000 third-party SaaS applications, including Salesforce, ServiceNow, Slack, Zoom, Dropbox, and many others. For most common SaaS tools, the integration work is minimal – you select the application, follow a guided configuration wizard, and the SAML or OIDC connection is established.

For on-premise web applications that cannot be moved to the cloud, Entra Application Proxy extends SSO without requiring you to open inbound firewall ports. Users access internal applications through a secure outbound tunnel – same SSO experience, no VPN required.

For custom line-of-business applications, Entra ID supports manual SAML and OIDC configuration, password-based SSO for legacy apps that cannot support modern protocols, and linked SSO for applications managed through separate identity systems.

Licence requirements for Entra ID SSO:

Microsoft 365 Business Premium – the most common licence tier for Australian SMBs – includes unlimited SSO application integrations, full MFA, and Conditional Access policies. This is typically sufficient for most small and mid-sized deployments. Entra ID P1 adds the Application Proxy and more advanced dynamic group features. Entra ID P2 adds Privileged Identity Management and risk-based Conditional Access policies that respond dynamically to sign-in risk signals.

Most Australian businesses we work with achieve a robust SSO and MFA implementation within their existing Microsoft 365 Business Premium licence without additional identity spend.

Step-by-Step SSO Implementation Guide

A disciplined implementation process is what separates a successful SSO deployment from one that creates new problems. Here is the approach we follow with Australian clients.

Phase One: Discovery and Planning

Start with a complete application inventory. Before touching any configuration, document every application in use across your organisation: SaaS tools, on-premise software, custom applications, and third-party integrations. For each one, record the authentication method currently in use, which SSO protocols it supports (SAML, OIDC, or neither), and how critical it is to operations. This audit defines the full scope of your SSO project and surfaces edge cases before they become problems during rollout.

Verify protocol support for each application. Do not assume – check vendor documentation or contact support directly. Applications that support neither SAML nor OIDC will require workarounds such as password vaulting (storing credentials in the IdP and auto-filling them) or proxy-based SSO. Document these applications separately; they will need different handling.

Select your Identity Provider. For Microsoft 365 environments, Entra ID is almost always the right answer. For organisations with complex multi-cloud requirements or a preference for a vendor-neutral IdP, Okta, JumpCloud, and Ping Identity are strong alternatives. This decision has long-term architectural implications – choose based on your current stack, your team’s capability, and where you expect to be in three years.

Audit and clean your user directory. This step is consistently underestimated and consistently critical. Before any SSO configuration, remove all stale accounts, standardise email address formats across systems, resolve duplicate identities, and align naming conventions. Mismatched user attributes between your directory and connected applications are the leading cause of post-SSO access failures. This work is not glamorous, but skipping it creates problems that are much harder to fix after go-live.

Define your access control model. Decide which applications each user group needs, and at what permission level. This becomes the blueprint for your Role-Based Access Control (RBAC) configuration in the IdP. Apply the principle of least privilege: every user should have access to what they need to perform their role – and nothing more. Forrester research shows that enforcing least privilege in identity management reduces insider threat risk by up to 75%.

Design your fallback access procedure. Your SSO Identity Provider will be a single point of failure. Before rollout, document the break-glass procedure for scenarios where the IdP is unavailable – how will staff access critical systems? Who has the emergency credentials? This procedure must exist before go-live, not after the first outage.

Phase Two: Configuration and Integration

Configure your Identity Provider. Set up your IdP tenant with your organisational policies: session timeout durations, Conditional Access rules, MFA requirements, and permitted sign-in locations and devices. For Entra ID, this includes configuring Security Defaults or – for more control – custom Conditional Access policies. Example policies worth configuring from the start: require MFA for all users, block legacy authentication protocols, require compliant devices for access to sensitive applications.

Enforce MFA before expanding SSO. This is non-negotiable. Deploy MFA at the IdP level and confirm it is working correctly before integrating additional applications into SSO. If you expand SSO scope before MFA is enforced, a single compromised password now unlocks every connected system simultaneously. MFA must come first.

Integrate applications in order of risk. Begin with non-critical, low-sensitivity applications. This limits the impact of any misconfiguration and gives your team practice before tackling business-critical systems. For each integration: register the application in the IdP, configure the SSO method (SAML or OIDC), exchange metadata or configuration details between IdP and SP, map user attributes, and test thoroughly in a non-production environment before going live.

Configure SCIM for automated provisioning. SCIM (System for Cross-domain Identity Management) automates the creation and removal of user accounts in connected applications. When a new employee is added to Entra ID, SCIM-enabled applications automatically create their account with the correct permissions. When they leave and their IdP account is disabled, SCIM automatically removes their access from every connected application. Without SCIM, offboarding requires manual removal from each system individually – a process prone to error and delay.

Test Single Logout (SLO). Verify that signing out of one application terminates the SSO session across all connected systems. Incomplete logout implementations leave active sessions that can be exploited. This is a commonly skipped test that creates real security gaps.

Enable comprehensive audit logging. Configure your IdP to log every sign-in event with application, user, device, IP address, location, and authentication method. Define log retention periods that meet your compliance obligations – under the Privacy Act and Essential Eight, this is typically a minimum of 12 months. Set up alerts for anomalous events: impossible travel, mass login failures, unusual access times, and MFA bypass attempts.

Phase Three: Rollout and Ongoing Management

Phased rollout by department. Start with your IT team, then a volunteer early adopter group from each department, then the broader organisation in waves. This approach surfaces user experience issues before they affect everyone, allows your helpdesk to build familiarity with SSO-related support requests, and reduces the change management risk that comes with organisation-wide changes rolled out simultaneously.

User communication and training. Tell users what is changing, why it is happening, and what they need to do. Provide self-service documentation for the new login experience and for MFA setup. Most SSO rollout friction comes from surprised users, not technical problems. Give people advance notice and a clear support path.

Establish ongoing access review cadence. Schedule quarterly reviews of who has access to what. Remove entitlements from users who have changed roles. Audit for accounts with excessive permissions. Privilege creep – where users accumulate permissions over time through role changes and special requests – is a silent but serious long-term risk in any identity management system.

Penetration test your identity infrastructure. Regular penetration testing that specifically targets your SSO configuration should be part of your security programme. Common findings include: unsigned SAML assertions being accepted, expired tokens not properly rejected, and Conditional Access policies with exploitable gaps. Our penetration testing services include targeted testing of authentication and identity systems.

Integrating MFA with SSO

SSO and MFA are not alternatives – they are designed to work together. SSO eliminates the friction of multiple logins. MFA ensures the single authentication event that does occur is genuinely secure.

Deploying SSO without MFA is the most dangerous configuration mistake in identity management. A single stolen, phished, or guessed password now unlocks every application in your business at once. There is no partial protection. This is why MFA must be configured and enforced at the IdP level before SSO rollout proceeds.

When MFA is enforced at the Identity Provider, it automatically applies to every application connected via SSO – you do not need to configure MFA separately for each application. This is one of the most significant operational advantages of centralised identity management.

Choosing the right MFA method:

SMS one-time passwords are no longer recommended as a primary MFA method. They are vulnerable to SIM-swapping attacks, and Singapore’s major banks began phasing them out in 2025 due to fraud rates. Where they remain in use, treat them as a last-resort fallback only.

Authenticator app push notifications (such as Microsoft Authenticator) offer a good balance of security and user experience for most employees. Enable number matching – where the user must enter a code displayed on the login screen into their authenticator app – to prevent MFA fatigue attacks where an attacker floods a user with push requests hoping they will approve one by mistake.

FIDO2 passkeys and hardware security keys (such as YubiKeys) are phishing-resistant MFA methods that are the recommended standard for privileged accounts, executives, finance staff, and IT administrators. They cannot be phished because the authentication is bound to the specific site’s domain – a fake login page simply does not work.

For most Australian SMBs, the right starting point is: Microsoft Authenticator push notifications with number matching enabled for all standard users, and FIDO2 or hardware keys for anyone with administrative access.

The network security team at CodeHyper can assess your current MFA posture and recommend the configuration appropriate to your risk profile.

SSO Security Best Practices for 2026

These practices address the actual failure modes we see in real deployments, not theoretical risks.

Use only industry-standard protocols. SAML 2.0, OAuth 2.0, and OIDC are community-audited and battle-tested. Avoid proprietary or custom SSO implementations – they introduce attack surface that has not been reviewed by the security research community.

Enforce least privilege at every layer. Assign permissions based on job function, reviewed and approved by a named authoriser. Do not assign broad access because it is convenient. Review role assignments quarterly and remove anything no longer needed.

Set session timeouts appropriate to sensitivity. Not all applications carry the same risk. A session timeout of eight hours may be acceptable for a low-risk productivity tool. A finance or HR system should have a much shorter timeout and may require step-up authentication for sensitive actions.

Validate tokens on every request. Service Providers must verify JWT signatures against the IdP’s public key on every authentication event, check token expiry, and validate issuer claims. Applications that cache tokens without proper validation are vulnerable to token replay attacks.

Treat your Identity Provider as your most critical system. If your IdP is compromised, everything is compromised. Restrict administrative access to a named list of individuals. Require MFA – ideally phishing-resistant MFA – for all IdP admin accounts. Monitor all configuration changes with alerts. Back up your IdP configuration regularly.

Configure Conditional Access policies. Risk-based Conditional Access applies additional authentication requirements when signals suggest elevated risk: an unfamiliar device, a sign-in from outside Australia, an unusual access time, or an attempt to reach a highly sensitive application. This adds an intelligent layer of protection beyond static MFA requirements.

Automate deprovisioning with SCIM. Manual offboarding is too slow. Deloitte’s research shows that automating user deprovisioning reduces orphaned accounts by 80%. Every day an ex-employee’s account remains active is a day of unnecessary exposure.

Conduct regular security audits. Your SSO configuration should be reviewed at least annually and after any significant change to your identity infrastructure or connected application set. Penetration testing targeting specifically authentication systems should be part of your annual security programme. We also recommend reviewing our guidance on understanding TTPs to understand how attackers approach identity systems.

Common SSO Risks and How to Avoid Them

SSO as a single point of failure. If your IdP goes down, all connected applications become inaccessible. Mitigation: choose an enterprise-grade IdP with a strong availability SLA, design a break-glass procedure for IdP outages, and test it before you need it.

SSO without MFA. Already addressed above – but worth repeating because it is the most common and most dangerous configuration error. No exceptions to this rule.

SAML misconfiguration. Flaws in SAML assertion validation have been responsible for serious enterprise breaches. Common errors: accepting unsigned assertions, failing to verify the audience restriction, not checking assertion expiry. Every SAML integration must be tested by someone who understands the attack surface, not just confirmed to “work.”

Token theft and session hijacking. Long-lived sessions and poor token storage (particularly in browser-accessible JavaScript contexts) create opportunities for session hijacking. Set appropriate timeout values, use secure and httpOnly cookie flags, and avoid storing tokens in localStorage.

MFA fatigue attacks. Attackers using push notification flooding to trick users into approving authentication requests have become a mainstream attack technique. Enable number matching and geographic context displays in your push notifications. For high-value targets, move to phishing-resistant FIDO2.

Orphaned accounts. Former employees retaining access through connected applications that were not SCIM-integrated and were manually offboarded incompletely. Conduct periodic access reviews and maintain a deprovisioning checklist that includes every SSO-connected application.

Shadow IT integration gaps. Employees using SaaS tools that are not connected to SSO – creating authentication blind spots outside your identity perimeter. Regular SaaS discovery audits (which your MDM or CASB solution can support) close this gap. For context on broader monitoring approaches, see our piece on why RMM is important.

A Real-World Example: SSO Implementation for a Sydney Professional Services Firm

One of CodeHyper’s clients – a 120-person professional services firm in Sydney – came to us after a security incident involving a former employee’s credentials. Despite a formal offboarding process, the departing employee’s account in one SaaS application had never been deactivated. It was accessed six weeks after their departure.

The firm was running Microsoft 365 Business Premium but had not configured Entra ID SSO beyond the default Microsoft app integrations. Staff were managing separate credentials for eight additional SaaS tools, including their project management platform, their CRM, and their document signing service.

We conducted a full application audit and identified all eight tools for SSO integration – six supported OIDC natively, one required SAML, and one required password-based SSO as it had no modern authentication support. We configured Entra ID Conditional Access policies requiring MFA for all users, enforcing compliant device sign-in for the CRM and document signing tool, and blocking legacy authentication protocols entirely.

SCIM was enabled for the five applications that supported it. For the remaining three, we configured deprovisioning runbooks in their IT documentation with clear step-by-step instructions for each application, ensuring offboarding would not be missed.

The result: a single login for all applications, MFA enforced across the entire stack, and a deprovisioning process that is now largely automated. Their cyber insurer was satisfied with the controls at renewal. The former employee scenario that had triggered the engagement would now be handled automatically within minutes of account deactivation.

This is the kind of outcome a well-planned SSO implementation delivers for a real Australian business.

If you are facing a similar situation, contact our team for a no-obligation assessment.

SSO and Australian Compliance Requirements

SSO implementation directly supports several compliance obligations that Australian businesses face.

The ACSC Essential Eight. The Australian Cyber Security Centre’s Essential Eight mitigation strategies include Multi-Factor Authentication as a mandatory control. Enforcing MFA through your SSO Identity Provider applies it consistently across all connected applications – a requirement for Essential Eight Maturity Level 2 and above. The Essential Eight also addresses restricting administrative privileges, which maps directly to least-privilege RBAC within your IdP. Our Essential Eight checklist provides a detailed breakdown of where SSO and identity management fit within each control.

The Privacy Act 1988 (Cth) and Australian Privacy Principles. The Privacy Act requires organisations to take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access. SSO with proper access controls and audit logging directly demonstrates this obligation: only authorised users can access systems containing personal data, and every access event is logged. The 2022 amendments to the Privacy Act strengthened the enforcement regime substantially. Access management failures that result in data exposure are increasingly resulting in regulatory action.

The NSW Cyber Security Policy. NSW Government agencies and their suppliers are required to meet specific controls under the NSW Cyber Security Policy, including requirements for access management and authentication. Private sector organisations working with NSW Government increasingly need to demonstrate alignment with these controls as part of contract requirements.

ISO 27001 and SOC 2. Both ISO 27001 and SOC 2 Type II include controls covering access management, authentication, privilege restriction, and audit logging. SSO implementation, properly documented and maintained, provides direct evidence for multiple control areas in both frameworks. Organisations pursuing or maintaining these certifications should ensure their SSO configuration is documented in their Information Security Management System and reviewed as part of internal audit cycles.

For businesses handling sensitive regulated data – healthcare, legal, financial services – SSO is not a nice-to-have. It is a demonstrable control that regulators and auditors will expect to see.

SSO Implementation Checklist

Use this before signing off on any SSO deployment.

Before you begin:

• Application inventory completed – all applications documented with current auth method and SSO protocol support confirmed
• User directory audited – stale accounts removed, email formats standardised, duplicates resolved
• Identity Provider selected and appropriately licenced
• Role-based access model defined for all user groups and departments
• Break-glass / fallback access procedure designed and documented
• Change management and user communication plan prepared

During implementation:

• IdP configured with session timeout policies and Conditional Access rules
• MFA enforced at IdP level and confirmed working before SSO expansion
• SAML metadata or OIDC configuration exchanged and validated for each application integration
• User attribute mapping verified – correct attributes flowing from IdP to each SP
• SCIM provisioning and deprovisioning configured for all SCIM-capable applications
• Single Logout (SLO) tested and confirmed working across all integrations
• Audit logging enabled with retention period matching compliance requirements
• Each integration tested with real user accounts across all role types

After go-live:

• User training and self-service documentation published
• Helpdesk team briefed on common SSO support scenarios
• Anomaly alerting rules active and tested
• Quarterly access review schedule in the calendar
• Penetration test of identity infrastructure scheduled
• IdP failover / disaster recovery scenario tested end-to-end
• Compliance alignment documented against relevant frameworks

Frequently Asked Questions

What is single sign-on and how does it work?

Single Sign-On is an authentication system that allows users to log in once and access multiple applications without re-entering credentials for each one. It works by having a trusted Identity Provider verify the user’s identity and issue a signed token that connected applications accept as proof of authentication. The user sees a seamless login experience; in the background, their identity is being securely passed between systems.

What is the difference between SAML and OpenID Connect for SSO?

SAML 2.0 is an XML-based protocol used primarily in enterprise and legacy application environments. It is well-established and broadly supported by older software. OpenID Connect (OIDC) is a more modern JSON-based protocol built on OAuth 2.0, better suited to cloud-native SaaS applications and mobile environments. Most organisations need to support both – SAML for legacy systems, OIDC for modern cloud tools. Microsoft 365 and most modern SaaS platforms use OIDC.

Is SSO secure? Does it create a dangerous single point of failure?

SSO is secure when implemented correctly. The main risk is that a compromised Identity Provider account grants access to all connected systems simultaneously. This risk is directly mitigated by enforcing strong MFA – ideally phishing-resistant – on all IdP accounts. The single point of failure concern is addressed by choosing an enterprise-grade IdP with high availability guarantees and designing a tested break-glass procedure for outage scenarios. A well-configured SSO deployment is substantially more secure than the alternative of password sprawl across dozens of separate systems.

What is the best Identity Provider for Australian SMBs?

For businesses already running Microsoft 365 – which describes the majority of Australian SMBs – Microsoft Entra ID is almost always the right choice. It is included in Microsoft 365 Business Premium at no additional cost, integrates natively with the entire Microsoft stack, and supports thousands of third-party SaaS applications. For organisations with complex multi-cloud requirements or a deliberate preference for vendor neutrality, Okta, JumpCloud, and Ping Identity are strong alternatives.

Does SSO work with on-premise applications?

Yes. Microsoft Entra Application Proxy allows SSO to extend to on-premise web applications without requiring inbound firewall ports. Users access internal applications through a secure outbound tunnel with the same SSO experience as cloud applications. For legacy thick-client applications that do not support SAML or OIDC, password-based SSO (where the IdP auto-fills credentials) provides a partial solution.

How long does SSO implementation take?

For a straightforward Microsoft 365 and Entra ID deployment integrating 5 to 10 applications, expect two to four weeks including planning, configuration, testing, and phased rollout. A larger deployment integrating 30 or more applications across a hybrid environment – especially one with significant legacy systems – may take three to six months. The most time-consuming phase is typically the application audit and directory cleanup, not the SSO configuration itself.

How does SSO relate to the Essential Eight?

The Essential Eight’s Multi-Factor Authentication control requires MFA to be enforced across all user authentication events, including access to internet-facing services and privileged operations. Deploying MFA through your SSO Identity Provider is the most efficient way to meet this control because it applies consistently across all connected applications from a single point of configuration. SSO also supports the Essential Eight’s Restrict Administrative Privileges control through RBAC and the principle of least privilege. Our Essential Eight checklist covers this in detail.

What is SCIM and why does it matter for SSO?

SCIM (System for Cross-domain Identity Management) is an open standard for automating user account management across identity systems and connected applications. In an SSO context, SCIM automates the creation of user accounts when a new employee is added to the IdP, and – critically – the removal of access from all connected applications when a user is offboarded. Without SCIM, deprovisioning relies on manual processes that are slow and error-prone. Orphaned accounts from departed employees are a significant and recurring finding in Australian cyber incidents.

Do I need SSO if I am a small business?

If your business uses more than three or four SaaS applications and has more than a handful of staff, SSO will save time and reduce risk. The security benefits – centralised access control, consistent MFA enforcement, complete audit logging, and automated offboarding – are relevant regardless of business size. Microsoft 365 Business Premium already includes the tools needed to implement a robust SSO deployment for most small businesses at no additional cost.