TL;DR: Google Cloud Identity-Aware Proxy centralizes access for GCP resources and HTTPS apps, but StrongDM’s comparison shows it can be a poor fit for multi-cloud infrastructure, SSH, RDP, databases, and Kubernetes because it needs extra configuration, has limited third-party integration, and does not protect activity within a project. For IAM teams, the issue is not access centralization alone but whether the control plane can govern credentials, sessions, and auditability across mixed environments.
At a glance
What this is: This is a comparison of Google Cloud IAP alternatives, and the key finding is that centralised access alone does not solve governance for multi-cloud infrastructure, server access, databases, or Kubernetes.
Why it matters: IAM, PAM, and infrastructure teams need more than a single access proxy when credentials, sessions, and audit evidence must span mixed environments and multiple protocols.
Context
Access centralisation is a control pattern, not a complete identity strategy. It can narrow who reaches a resource, but it does not automatically govern what happens after access is granted, especially when the environment includes servers, databases, Kubernetes, and multiple clouds.
That distinction matters for NHI and IAM programmes because the access plane, credential plane, and audit plane are often split across tools. When a control works well for HTTPS applications in one cloud but weakly for heterogeneous infrastructure, teams inherit blind spots in session visibility, credential handling, and offboarding consistency.
Key questions
Q: What breaks when access centralisation does not cover every protocol and cloud?
A: The control breaks at the boundary between authenticated entry and governed activity. A platform may still prove who connected, but if SSH, RDP, databases, and Kubernetes follow different policy and logging paths, the organisation loses a single audit model and consistent revocation behaviour across its infrastructure.
Q: Why do multi-cloud environments expose weaknesses in centralised access controls?
A: Because multi-cloud environments multiply the places where identity, policy, and logs can diverge. A control that works cleanly in one provider often needs extra configuration or separate integrations elsewhere, and each exception reduces the chance that access, session, and offboarding rules stay consistent end to end.
Q: How can security teams tell whether an access platform is actually reducing risk?
A: Measure whether access requests, role changes, and offboarding events complete across all connected systems without manual cleanup. Strong evidence includes fewer orphaned accounts, fewer stale entitlements, and better visibility into applications that were previously outside the directory.
Q: What is the difference between authentication protocol choice and access governance?
A: Authentication protocol choice determines how identity is verified, but access governance determines whether that identity should keep access over time. SAML and LDAP both authenticate, yet neither automatically enforces rotation, review, ownership, or offboarding. Practitioners need both protocol fit and governance controls to manage NHIs safely.
Technical breakdown
Where access centralisation stops helping
Identity-Aware Proxy is designed to mediate access to Google Cloud resources and HTTPS applications by checking identity before a request reaches the target. That model works best when the resource set is narrow and the access pattern is web-centric. It becomes less complete when teams also need SSH, RDP, databases, and Kubernetes, because those protocols carry different session semantics, different credential handling, and different audit needs. The architectural limit is not authentication itself, but the scope of what the proxy can govern once access is already established.
Practical implication: Treat centralised access as one control layer and verify whether it also covers post-authentication visibility, credential exposure, and session recording.
Why multi-cloud access changes the governance problem
Multi-cloud access creates a governance problem because each cloud, platform, and protocol can introduce its own trust boundary, identity mapping, and logging path. A control that is tightly integrated with one provider may require extra configuration to reach beyond it, and that friction often pushes teams back toward separate tools or exception paths. Once that happens, the programme no longer has one coherent access model. Instead, it has a set of partial controls with different enforcement depths across infrastructure types.
Practical implication: Map where policy enforcement, logging, and credential issuance diverge across clouds before standardising on any access control layer.
Why activity inside the project boundary still matters
A control that authorises entry to a project or application can still leave internal activity insufficiently governed. That matters because lateral misuse, overbroad entitlements, and unlogged administrative actions often occur after initial access succeeds. In practice, this is where access centralisation can create a false sense of completeness: the front door is guarded, but the workload, database, or cluster activity remains outside the same governance envelope. For identity programmes, the missing layer is not just admission control but continuous session and action-level oversight.
Practical implication: Check whether your access platform records the commands, queries, and administrative actions that actually create risk after login.
Threat narrative
Attacker objective: The objective is to reach and use authorised infrastructure with enough flexibility that the organisation loses consistent control over session activity, auditability, and access scope.
- Entry occurs through valid identity-based access to a cloud resource or HTTPS application, with the proxy enforcing who can connect but not necessarily standardising every downstream protocol or environment.
- Privilege use then shifts into SSH, RDP, database, or Kubernetes activity, where the main risk is uncontrolled action after authentication rather than simple initial access.
- Impact appears when session activity, credential handling, or audit logging is fragmented across tools, leaving the organisation with incomplete evidence and inconsistent governance across the environment.
Breaches seen in the wild
- Storm-2949 Azure Breach: Storm-2949 social engineering attack turns one cloud identity compromise into full Azure tenant breach.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Access centralisation is not the same thing as identity governance. Strong authentication at the edge does not automatically produce consistent control over credentials, sessions, and audit trails once access crosses protocols or clouds. The stronger the environment mix, the more obvious it becomes that entry control and governance control are different disciplines. Practitioners should stop treating a single access proxy as a complete governance model.
Multi-cloud infrastructure exposes the control-plane gap in most access architectures. A tool optimised for GCP and HTTPS flows can leave SSH, RDP, databases, and Kubernetes governed through different paths. That is not a minor integration issue, it is a structural boundary in the programme. The implication is that teams must evaluate whether their access plane can actually span the full operational surface they claim to govern.
Session visibility is the real test of access centralisation. If a platform can authenticate a user but cannot consistently log what that user does after entry, the organisation still lacks enforceable accountability. In NHI terms, the control fails when the resource interaction becomes the security event. Teams should judge tools by whether they govern the action layer, not just the login layer.
Identity blast radius is the right concept for comparing IAP alternatives. The issue is not whether access is centralised, but how far one compromised or overextended identity can move across the stack before governance catches up. When credentials, session controls, and audit evidence are fragmented, the blast radius expands across infrastructure types. Practitioners should design for containment across the full access path, not only at the initial gate.
What this signals
Access centralisation only becomes useful when it survives protocol diversity. The practical test for IAM teams is whether one control model can govern web apps, servers, databases, and Kubernetes without forcing separate exceptions for each environment. If it cannot, the organisation has central login points but not central governance.
Identity blast radius is the better design lens than access convenience. Teams should measure how far one identity can move once authenticated, because that reveals whether their control plane truly limits lateral use or simply simplifies the front door. In mixed estates, governance must follow the session, not stop at the sign-in event.
For practitioners
- Define the governed access surface List every resource class that must be controlled through one policy model, including databases, servers, Kubernetes, SSH, RDP, and HTTPS applications. Then identify where your current access control stack fragments by protocol or cloud provider.
- Test post-authentication visibility Verify that the platform records commands, queries, and administrative actions after login, not just successful authentication events. If it cannot produce session-level evidence across the environments you operate, it is only solving half the problem.
- Align offboarding to actual resource access Make sure disabling the upstream identity or SSO session actually revokes access to every governed resource class, including third-party and cross-cloud targets. If revocation depends on manual cleanup, the access model is not operationally complete.
- Compare tools by audit completeness Score alternatives on whether they can standardise logs, session recordings, and credential hiding across mixed infrastructure rather than only within one cloud. The practical question is whether the control plane can preserve evidence at the point where risk is created.
Key takeaways
- The core issue is not whether access can be centralised, but whether the control plane still governs credentials, sessions, and evidence after access is granted.
- Multi-cloud and multi-protocol estates expose the limits of single-cloud access models because enforcement and logging can fragment across tools.
- IAM teams should evaluate alternatives by session visibility, offboarding completeness, and audit consistency across all resource types.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on whether access remains governed across mixed environments after authentication. |
| Recommendation — Use PR.AA-05 to verify access permissions stay consistent across clouds, protocols, and resource types. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The comparison repeatedly turns on credential handling, revocation, and access scope. |
| IA-9 — Service Identification and Authentication | The article touches infrastructure, workloads, and managed resources that rely on non-human authentication. | |
| Recommendation — Apply IA-5 to govern authenticator lifecycle and revoke credentials cleanly across managed resources. Use IA-9 where services, servers, and workloads authenticate across managed infrastructure. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Weak access boundaries can let authenticated activity expand beyond the intended control surface. |
| Recommendation — Map access gaps to TA0006 and TA0008 when evaluating how far a valid identity can move. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is fundamentally about cloud access governance across hybrid and multi-cloud environments. |
| Recommendation — Use IAM controls to standardise identity enforcement across cloud and hybrid resources. | ||
Key terms
- Credential Centralisation: Credential centralisation places password policy enforcement, storage, and auditing under a shared identity control layer instead of many application-specific stores. The goal is consistent governance, simpler monitoring, and safer migration, especially in environments where legacy and modern systems must coexist.
- Session Visibility: Session visibility is the ability to see what an identity actually did during an access session, not just that access occurred. It usually includes commands, queries, timestamps, and resource changes, which makes it vital for forensics, scoping, and accountability after a breach.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Post-Authentication Governance: Post-authentication governance is the control layer that manages access after an identity has already been verified. It covers entitlements, approvals, privilege changes and removal, and it is where many identity programmes fail because they stop at login assurance.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management 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 programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org