TL;DR: Opal Security argues that many growing teams do not need to replace Google Workspace with a new IdP to improve access governance, because the core gap is authorization and lifecycle control rather than authentication. Keeping Google and adding composable governance can deliver least privilege, audit trails, and JIT access without migration overhead.
At a glance
What this is: This is an analysis of why some organisations can keep Google Workspace as their IdP while layering composable access governance on top to close authorization and lifecycle gaps.
Why it matters: It matters because IAM teams often over-rotate on IdP replacement when the actual control failure sits in access governance, lifecycle enforcement, and privileged access reduction.
👉 Read Opal Security's analysis of composable identity governance without an IdP migration
Context
Many fast-growing organisations start with Google Workspace for authentication because it is familiar and easy to deploy. The security problem appears later, when access governance, lifecycle control, and auditability become more important than basic sign-in.
The article's central claim is that replacing the IdP is not always the right fix for access risk. In many programmes, the more relevant question is how to govern who can access what, when, and for how long across human and non-human identities.
Key questions
Q: What breaks when authentication and authorization are treated as the same control?
A: Teams lose visibility into whether the real problem is identity proof or permission scope. That leads to weak remediation, because fixing login assurance does not reduce access blast radius, and tightening roles does not stop bad authentication. Mature IAM programmes separate the two so they can measure, govern, and audit them independently.
Q: When should organisations prioritise access governance over an IdP migration?
A: When the main issue is who can access what, when, and for how long rather than unsupported federation or a broken authentication layer. If the IdP already meets sign-in needs, adding governance is usually faster, cheaper, and less disruptive than replacing the foundation.
Q: What do security teams get wrong about just-in-time access in mixed environments?
A: They assume JIT is a single control when it is really a boundary-dependent control. If temporary access works only in the main app catalogue, then every system outside that catalogue still relies on manual handling. The result is uneven privilege reduction and weak revocation assurance.
Q: How should security teams govern human and non-human access in the same programme?
A: They should use one governance model for ownership, approval, review, and revocation, but apply it differently by actor type. Human identities rely on joiner-mover-leaver processes, while NHIs need secrets, certificates, and token lifecycle controls. AI agents add runtime behaviour that must also be monitored. The goal is consistent oversight, not identical workflows for every identity type.
Technical breakdown
Authentication and authorization solve different problems
An identity provider answers the question of who a user is, while access governance answers whether that identity should have a given entitlement at a given moment. The article's core point is that teams often treat those as one control plane, then reach for a migration when the real gap is entitlement governance, not login. That distinction matters because authentication strength does not remove standing access, weak approvals, or stale lifecycle states. Practical implication: separate sign-in architecture from authorization governance before deciding whether an IdP change is justified.
Practical implication: separate sign-in architecture from authorization governance before deciding whether an IdP change is justified.
Why JIT access changes the blast radius model
Just-in-time access reduces standing privilege by issuing access only when a task requires it, then withdrawing it when the task ends. That changes the risk model from persistent access review to time-bounded entitlement issuance, which is more useful when teams want faster movement without broader privilege exposure. In the article's framing, JIT is one of the main reasons a composable layer can cover governance needs without forcing a full identity stack swap. Practical implication: use JIT to constrain elevated access at issuance time, not after the fact.
Practical implication: use JIT to constrain elevated access at issuance time, not after the fact.
Composable identity stacks are becoming the operating model
A composable identity stack is a modular approach in which authentication, authorization, approvals, and reviews are separated across purpose-built layers instead of concentrated in a single platform. This article argues that modern security programmes increasingly work that way because different control problems move at different speeds. Google can remain the authentication layer while another system handles governance decisions, workflows, and audits. Practical implication: map which controls must stay in the IdP and which should be externalised into governance layers.
Practical implication: map which controls must stay in the IdP and which should be externalised into governance layers.
NHI Mgmt Group analysis
Identity governance is not the same control problem as authentication. The article is right to separate IdP choice from access governance because those controls answer different questions. Authentication proves identity at sign-in, but it does not decide whether access should exist, how long it should last, or whether approvals are auditable. For practitioners, that means the migration decision should follow the control gap, not the other way around.
Composable governance lowers the penalty for getting the architecture wrong. When teams can keep an existing IdP and layer authorization, reviews, and JIT access on top, they avoid turning every governance gap into a platform replacement project. That is a meaningful programme design shift for startups and fast-growing SaaS organisations. The implication is that identity architecture can become iterative rather than all-or-nothing.
Unified governance across human and non-human identities is now the more important boundary. The article's most useful signal is that access governance has to span employees, service accounts, and AI agents, not just human users. That aligns with NHI governance thinking: the control plane should follow the identity subject and the access risk, not the login product. Practitioners should treat cross-identity governance as the durable requirement.
Least privilege is increasingly a runtime governance problem, not a directory problem. Standing access becomes the real issue once organisations grow beyond a small team, because the directory may authenticate correctly while entitlements drift. The article's composable model reflects that shift: policy, approvals, and lifecycle controls become the place where least privilege is enforced. Practitioners should design for access decisions at the point of need, not only at account creation.
From our research library:
- The average worker in a typical enterprise holds 96,000 entitlements, and 38% of IdP accounts are dormant, according to Veza's 2026 State of Identity and Access Report.
What this signals
Composable identity governance is becoming a design pattern, not a niche workaround. The article reflects a broader shift in IAM programmes: authentication platforms no longer need to carry every access decision themselves. As organisations separate IdP function from governance function, the real question becomes where policy, approval, and review logic should live.
Google-native environments can support serious access governance when the programme is built around task-scoped entitlement, not directory replacement. That matters for teams trying to reduce migration risk while still improving auditability, privilege hygiene, and lifecycle control across human and non-human identities.
For practitioners
- Separate authentication from authorization design Document which controls belong to the IdP and which belong to access governance, approvals, and lifecycle enforcement. Use that split to decide whether the real gap is sign-in architecture or entitlement control.
- Adopt just-in-time access for elevated roles Replace persistent privileged access with task-scoped issuance so access exists only for the duration of the work. Tie approvals to the specific access request and revoke automatically when the task closes.
- Extend governance to non-human identities Include service accounts, tokens, and AI agents in the same review and approval model used for human users. The article's premise only holds if governance spans every identity that can consume access.
- Measure lifecycle control, not just login success Track whether access reviews are completed, whether approvals are auditable, and whether access expires when it should. A healthy authentication stack can still leave governance gaps if entitlements persist unchecked.
Key takeaways
- The article's main point is that access governance problems often get mistaken for identity provider problems, which leads to unnecessary platform migration.
- Its practical case is strongest for teams that already have acceptable authentication but still need better approvals, reviews, and time-bounded access.
- The control lesson is to separate login infrastructure from entitlement governance so least privilege can be enforced without forcing a full IdP switch.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on reducing standing access across human and non-human identities. |
| NHI-01 — Improper Offboarding | Lifecycle governance is a core theme because access should end when the task or role ends. | |
| Recommendation — Use NHI-05 to reduce standing entitlements and shift privileged access to task-scoped issuance. Apply NHI-01 to ensure access is revoked when identity relationships or tasks end. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing entitlements, approvals, and access scope beyond authentication. |
| GV.RM-01 — Risk Management Strategy | The piece argues for choosing architecture based on governance risk rather than migration habit. | |
| Recommendation — Enforce PR.AA-05 by reviewing entitlements separately from sign-in and limiting access to business need. Align identity architecture decisions to a risk strategy instead of defaulting to an IdP replacement. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the governing principle behind the article's JIT and access governance approach. |
| Recommendation — Apply AC-6 to minimise standing access and require approvals for elevated entitlements. | ||
Key terms
- Composable identity stack: A composable identity stack splits authentication, authorization, HR triggers, ticketing, and audit functions into separate components. The model can improve flexibility and speed, but only if policy and lifecycle signals stay connected enough to prevent entitlement drift.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
What's in the full article
Opal Security's full analysis covers the operational detail this post intentionally leaves for the source:
- How Google Workspace and Opal divide authentication, approval, and lifecycle responsibilities in a real deployment
- Examples of where composable governance reduces migration overhead compared with a full IdP replacement
- The specific customer-facing workflow changes involved in adding JIT access and automated reviews
- The conditions under which Google is still the right fit and when a different IdP is justified
Deepen your knowledge
NHI governance, identity lifecycle, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org