Yes, as far as possible. Different technical back ends can still feed the same request, approval, and fulfilment pattern, which reduces variance and makes the governance model easier to audit. The practical goal is one decisioning process, not one authentication protocol.
Why One Workflow Is the Better Default for SSO and Non-SSO Apps
The practical answer is yes: keep one workflow wherever you can, even if the technical route differs behind the scenes. The business decision, approval, fulfilment, and review steps should stay consistent, because that is what makes access governance repeatable. When the workflow is the same, the team can compare exceptions cleanly and the control model stays understandable.
That does not mean every application must authenticate the same way. SSO and non-SSO systems can still use different technical back ends, but they should enter the same intake, approval, fulfilment, and certification pattern. This keeps the operating model stable while allowing the identity architecture underneath it to vary by application capability and risk.
The strongest version of this approach is to standardise the decisioning process, not the protocol. For example, the same request path can handle federated SSO, local accounts, service credentials, or legacy access exceptions, as long as the ownership, approver, evidence, and review steps are consistent. That is the difference between a controlled exception and an uncontrolled one.
Where Teams Usually Break the Model
The workflow usually fragments when teams let application history dictate governance. SSO apps get one process, legacy apps get another, and service or admin access gets a third. Over time that creates inconsistent approvals, different evidence standards, and no reliable way to compare who approved what and why.
Another common failure is confusing authentication design with access governance. SSO is an authentication pattern, while the workflow is the governance path that decides whether access should exist at all, who approves it, and when it is removed. OpenID Connect Core 1.0 describes the SSO side of that boundary, but the workflow should remain broader than any single protocol.
Legacy or non-SSO applications often expose the cracks most clearly. They need the same ownership and recertification discipline as federated apps, even if fulfilment is manual. A common mistake is to treat them as exceptions that sit outside the normal access lifecycle, which is how access reviews become incomplete and entitlement sprawl starts to grow.
How to Design a Single Access Workflow That Still Handles Mixed Back Ends
Start by separating the workflow from the implementation path. The request should capture the app, role, business justification, approver, expiry, and access method, while the fulfilment step decides whether the access is delivered through SSO, local account creation, group membership, or a downstream system ticket. That separation lets IAM teams preserve consistency without forcing every target system into one authentication model.
For workforce access, a unified operating model is easier to run when supported by a strong identity platform and clear lifecycle controls. IAM and Identity Provider Buyer's Guide is useful for aligning SSO, lifecycle, and access management decisions, while the Workforce Identity Security Guide reinforces the same governance pattern across SSO, federation, provisioning, and recovery.
The lifecycle side matters just as much for non-SSO apps. If a request can bypass the standard joiner-mover-leaver flow, the workflow is no longer truly one workflow. NHI Lifecycle Management Guide is a useful reference for the broader lifecycle discipline of provisioning, rotation, and offboarding, and the same logic applies to access paths that are not federated.
Risk and Threat Considerations
Mixed workflows create control drift when different access paths receive different scrutiny. That weakens auditability, makes exceptions harder to spot, and increases the chance that a legacy or non-SSO path becomes the easiest way to obtain standing access. In practice, the risk is not just operational inconsistency, it is silent overgranting and weak removal discipline.
Failure mechanism: Separate workflows usually lead to separate approval standards, different evidence retention, and uneven revocation handling, so one access path becomes easier to approve and harder to verify than the others.
Impact: The organisation gets inconsistent access decisions, higher exposure to orphaned or excessive access, and a weaker audit trail when an access review or incident investigation is needed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Mixed SSO and non-SSO access still needs consistent user authentication governance. |
| AC-6 — Least Privilege | A single workflow should enforce consistent entitlement decisions across app types. | |
| IA-5 — Authenticator Management | Non-SSO and SSO paths both depend on controlled credential lifecycle and recovery. | |
| Recommendation — Apply IA-2 consistently across all workforce access paths. Use AC-6 to right-size access regardless of SSO method. Manage authenticators centrally and remove inconsistent local exceptions. | ||
| NIST CSF 2.0 | PR.AA-04 — Identity Management, Authentication, and Access Control | The question is about consistent access governance across authentication back ends. |
| GV.OC-03 — Roles, Responsibilities, and Authorities | One workflow depends on clear ownership for requests, approvals, and fulfilment. | |
| Recommendation — Standardise identity and access workflows across all application types. Assign clear ownership for approval and fulfilment decisions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | A unified workflow is an access-control governance decision across systems. |
| Recommendation — Define one access control process and apply it consistently. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The topic is about IAM workflow consistency across federated and non-federated apps. |
| Recommendation — Align IAM governance so SSO and non-SSO follow one process. | ||
Practitioner Guidance
What to prioritise: Standardise the request and approval workflow first, then allow the fulfilment step to vary by application type. That gives you one governance model while still accommodating legacy applications, federation gaps, and manual provisioning.
What to verify: Every access path, including non-SSO, must have the same minimum evidence set: owner, approver, business need, expiry or review point, and removal trigger. If any path cannot produce that evidence, treat it as an exception that needs remediation, not as a separate normal process.
Common mistake: Teams often declare success when SSO apps are automated, then leave non-SSO applications in an ad hoc queue. That creates two operating models, which is exactly what drives inconsistency, audit friction, and weak offboarding.
Practitioner takeaway: One workflow is the right goal because governance should be uniform even when authentication is not. If the front end differs, the decisioning logic should still be the same, or the IAM programme will accumulate avoidable exceptions and control gaps.