The Definitive Guide to Choosing a Cloud-Native Access Control Vendor
Andrew Baumbach
•
Product Marketing Engineer
•
A practical buyer's framework for evaluating cloud-native access control platforms, covering must-have features, integration requirements, Zero Trust alignment, and a step-by-step selection process. Start with the Twingate documentation if you want to see how a ZTNA layer fits into the picture.
Most enterprise access incidents in the last few years didn't come from sophisticated zero-days. They came from a misconfigured IAM role, a long-lived access key sitting in a repo, or a VPN account belonging to a contractor who left eight months ago.
According to the 2024 Verizon DBIR stolen credentials appear in roughly 31% of breaches over the past decade, and the IBM Cost of a Data Breach Report has been flagging stolen or compromised credentials as the most common initial access vector for years running.
It's not that there's a lack of access control products. The problem is that most of these were designed for a world where the perimeter was a building, not a control plane scattered across AWS, Azure, GCP, a few SaaS apps, and whatever a developer just spun up in a sandbox account.
Cloud-native access control is the response to that shift, and picking the right vendor has gotten genuinely hard.
This guide is a working framework for that decision. It covers what cloud-native access control actually means, the capabilities you should expect on the shortlist, how to evaluate vendors against your own environment, and a selection process that won't leave you stuck mid-rollout.
What "cloud-native access control" actually means
Cloud-native access control is a category of platforms that govern who and what can reach resources across cloud infrastructure, SaaS, and private networks, using identity and context as the primary control rather than network location.
A few things are worth pulling apart in that definition.
Identity-first, not network-first
Legacy access control assumes "inside the network" means "trusted." Cloud-native access control assumes nothing about location. Every request is authenticated and authorized against an identity, a device, and a policy, regardless of whether the request originated from a corporate office or a coffee shop.
Resource-scoped, not subnet-scoped
Instead of granting access to a 10.0.0.0/16 range and hoping for the best, a cloud-native platform grants access to a specific resource (a database, an API endpoint, an internal app) for a specific identity.
Continuous, not session-based
Authorization decisions are made on every request, not once at session start. If a device's posture changes mid-session or a user is offboarded in the IdP, access can be revoked immediately.
This is what people usually mean when they say Zero Trust Network Access (ZTNA), and it's also the through-line for adjacent categories: Cloud Infrastructure Entitlement Management (CIEM), Cloud Security Posture Management (CSPM), and Identity-Aware Proxies (IAP).
How it differs from perimeter-based models
Dimension | Perimeter-based (VPN, firewall ACLs) | Cloud-native access control |
|---|---|---|
Trust model | Implicit trust inside the network | No implicit trust; every request verified |
Access scope | Network segment or subnet | Specific resource or workload |
Identity binding | Loose; often shared service accounts | Tight; bound to IdP user and device |
Exposed surface | Inbound ports, public VPN gateways | Outbound-only connections, no inbound exposure |
Policy enforcement point | Network edge | Closer to the resource, often inline |
Visibility | Flow logs, perimeter telemetry | Per-request, per-identity audit logs |
The perimeter model isn't broken because firewalls stopped working. It's broken because most resources you care about aren't behind a single perimeter anymore.
Why this matters now
Three pressures are pushing access control off the perimeter and into identity.
Misconfiguration is the dominant failure mode
Gartner has been saying for years that through 2025, 99% of cloud security failures will be the customer's fault, and the underlying pattern is consistent: a bucket left public, a security group opened to 0.0.0.0/0 "just for testing," an IAM role with * on the actions.
Cloud-native access control platforms address this by replacing implicit network access with explicit, identity-bound policies that are harder to fat-finger.
Standing privilege accumulates
A typical enterprise user touches dozens of cloud accounts, SaaS apps, and internal services. CIEM research from Sysdig, Wiz, and others consistently finds that over 90% of granted cloud permissions go unused. Every unused permission is a potential lateral movement path.
Lateral movement is the actual blast radius
Once an attacker has a foothold, perimeter-based networks let them move laterally with little friction. Microsoft's analysis of the 2023 Midnight Blizzard intrusion showed exactly this: an OAuth app abuse that pivoted across tenants because trust relationships were too broad. ZTNA, microsegmentation, and least-privilege enforcement are what shrink the blast radius.
If your current access stack can't answer the question "what exactly can this identity reach right now, and from which device?" you have a cloud-native access control problem.
The evaluation framework
A serious shortlist should cover six categories. Score vendors against each, weighted by what your environment actually looks like.
1. Platform features
The capability surface varies widely across vendors. At minimum, ask:
Zero Trust Network Access (ZTNA): Identity- and device-aware access to private resources without exposing them to the internet. This is the load-bearing capability for most enterprise use cases.
CIEM: Visibility into who can do what across cloud accounts, with the ability to flag and right-size over-privileged identities, including non-human identities.
CSPM: Continuous evaluation of cloud resource configuration against benchmarks (CIS, NIST, PCI). Useful to have unified; not always a dealbreaker if you already have it.
Unified visibility: A single audit and policy view across cloud, SaaS, and private network access. Federated dashboards across three tools is not the same thing.
IaC scanning: Catching misconfigurations in Terraform, CloudFormation, or Pulumi before they reach production. Increasingly table stakes.
Device posture checks: Verifying OS version, disk encryption, EDR status, and MDM enrollment before granting access. This is what closes the "compromised laptop with valid credentials" gap.
Session-level controls: Recording, just-in-time elevation, and the ability to terminate sessions mid-stream.
Be honest about what you actually need versus what looks good in a feature matrix. CIEM and CSPM are often handled by adjacent tools (Wiz, Orca, Prisma Cloud), and trying to consolidate everything into one platform sometimes means accepting the worst tool in each category.
2. Integration requirements
Access control is only as good as the systems it plugs into.
Identity provider: SCIM-based provisioning, SAML and OIDC support, and group-based policy assignment against Okta, Entra ID, Google Workspace, JumpCloud, or whatever you run. If you have more than one IdP (common after acquisitions), confirm multi-IdP support.
CI/CD: API-driven configuration so access policies can be defined in code and managed by the same pipelines as the rest of your infrastructure. Terraform providers and Pulumi support matter here.
SIEM and observability: Streaming audit logs to Splunk, Datadog, Sumo Logic, or whatever you use for detection. Pull-based daily exports are not enough for incident response.
MDM and EDR: Pulling device posture signals from Jamf, Intune, Kandji, CrowdStrike, or SentinelOne to inform access decisions.
Secrets and PAM: Coexistence with HashiCorp Vault, AWS Secrets Manager, CyberArk, or Teleport, depending on what you're using for privileged access today.
Anything that requires a custom integration or a professional services engagement should be flagged as a risk.
3. Multi-cloud and hybrid support
A surprising number of "cloud-native" vendors are quietly cloud-specific. Ask:
Does the platform run identically across AWS, Azure, GCP, and on-prem?
How are private resources in different VPCs, subscriptions, or data centers reached? Is there a connector or gateway component, and what does its failure mode look like?
Are there latency or throughput differences depending on region?
How does the platform handle resources behind NAT, in air-gapped environments, or in customer-managed Kubernetes clusters?
For most enterprises, the answer needs to include "hybrid" for at least the next five years. Don't accept a roadmap commitment in place of a shipping capability.
4. Zero Trust alignment
Zero Trust is a model, not a product, but you can test how seriously a vendor takes it by asking:
Are connections to private resources outbound-only from your network, or do they require inbound firewall rules?
Is every request verified independently, or is trust established once at session start?
Are authorization decisions enforced at the resource (or close to it), or at a centralized gateway?
Are policies expressed in terms of identities and resources, or in terms of IP addresses and ports?
What happens to active sessions when a user is removed from a group in the IdP?
A platform that requires opening inbound ports, uses long-lived sessions, or expresses policy in CIDR ranges is not doing Zero Trust, regardless of marketing.
5. Performance and scalability
ZTNA platforms sit in the data path. They will be blamed for every slow query and dropped video call until proven innocent.
Throughput and latency: Request published benchmarks and run your own. Pay attention to behavior under sustained load, not just burst.
Peer-to-peer vs relayed traffic: Architectures that establish direct connections between client and resource (with relays as fallback) generally outperform always-relayed architectures.
Geographic distribution: Where are the relays and points of presence? A user in Singapore connecting to a resource in Frankfurt via a relay in Virginia is going to have a bad day.
Failure isolation: When the vendor's control plane goes down, do existing sessions stay up? Twingate's architecture, for example, separates the control plane (the Controller) from the data plane, which is why customer traffic kept flowing during a notable AWS us-east-1 incident in 2023 even though parts of the broader internet didn't.
Client footprint: Resource consumption, battery impact on mobile, support for the OSes and architectures your fleet actually uses (including Linux and ARM).
6. Commercial considerations
The category is competitive enough that you should expect:
Per-user pricing with clear tiering: Per-resource or per-connector pricing tends to penalize the patterns you actually want (lots of small, narrowly scoped resources).
A free or low-cost tier for evaluation: Anyone serious about a PoC will give you something usable for a real test.
A proof of concept that mirrors production: A two-week PoC with a real workload, real users, and real integrations tells you more than a six-week feature checklist exercise.
Support SLAs that match your operational profile: 24/7 support with named TAMs at the enterprise tier is reasonable to expect.
A clear deprecation and version support policy: Especially for the client and connector components. Twingate, for example, publishes a 12-month rolling support window for clients, which makes patch planning predictable.
Where ZTNA fits, specifically
Cloud-native access control is the umbrella. ZTNA is the specific layer that handles access to private resources: internal apps, dev environments, production databases, SSH targets, Kubernetes APIs, on-prem systems.
For most enterprises, ZTNA is the first thing to fix because it's where VPNs have been failing for the longest. The pattern that works:
Identity-aware: every connection is bound to an authenticated user and a known device, with the IdP as the source of truth.
Resource-scoped: users get access to specific resources, not network segments.
Outbound-only: connectors deployed in your environment make outbound connections to the control plane. No inbound firewall rules, no exposed ports, no public VPN gateway to scan and exploit.
Continuous: every request is verified against current policy, current group membership, and current device posture.
Audited: per-request logs streamed to your SIEM, attributable to a specific user and device.
This is the model Twingate is built around. Connectors sit behind your firewall and dial out to the Controller. Clients on user devices intercept traffic for defined resources, request authorization, and establish a tunnel to a Connector. The Connector independently verifies the request against its own copy of the ACL before proxying to the resource.
No single component compromise grants unauthorized access, and there is nothing to expose to the public internet.
The practical result for an IT or security team: VPN concentrators come out, contractor accounts stop being a quarterly cleanup project, audit logs become useful for actual investigations, and the user experience stops being a recurring help desk ticket.
A selection process that works
Here's the sequence I'd recommend running, in order.
1. Inventory what you're protecting: Before you talk to a vendor, list the resources users actually need to reach: internal apps, databases, SSH targets, Kubernetes clusters, third-party SaaS via private link, on-prem systems. Group them by sensitivity. This list becomes your scoring rubric.
2. Inventory who needs access: Employees, contractors, vendors, service accounts, CI runners, AI agents. Map each group to the resources they touch. This will surface uncomfortable findings (it always does) before any vendor demo.
3. Define the integration surface: IdP, MDM, EDR, SIEM, secrets manager, IaC tooling. Anything a vendor can't integrate with cleanly is a long-term tax.
4. Build a 5-criterion shortlist: Use the framework above to score 3 to 4 vendors. Don't shortlist 10; you'll never run real PoCs.
5. Run real PoCs, not feature demos: Pick one moderately complex use case (say, replacing VPN access for a production environment for a 20-person team) and run it end to end with each finalist. Insist on:
Real IdP integration with your actual IdP
Real device posture checks against your actual MDM
Real audit log streaming to your actual SIEM
Real users, not just the security team
6. Test failure modes. What happens when the vendor's control plane is unavailable? What happens when a Connector dies? What happens when a user's device fails posture mid-session? What happens when you remove a user from a group in the IdP?
7. Validate commercials. Get pricing in writing, including overages, premium support tiers, and renewal mechanics. Confirm the contract terms for data residency, audit rights, and termination.
8. Stage the deployment. Pick one team or one resource group. Roll out, gather feedback, expand. Trying to cut over the whole organization in one weekend is how you end up reinstalling the VPN.
9. Decommission what you replaced. This is the step that gets skipped. If the VPN concentrator is still running six months after the ZTNA rollout, you didn't reduce attack surface, you added another control. Set a hard date and enforce it.
Closing
For more detail on how Twingate's architecture handles identity, device posture, outbound-only connectivity, and audit logging, the Twingate documentation is the best place to start. The Security Policies and Connectors sections are particularly relevant if you're working through the evaluation framework above.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
The Definitive Guide to Choosing a Cloud-Native Access Control Vendor
Andrew Baumbach
•
Product Marketing Engineer
•
A practical buyer's framework for evaluating cloud-native access control platforms, covering must-have features, integration requirements, Zero Trust alignment, and a step-by-step selection process. Start with the Twingate documentation if you want to see how a ZTNA layer fits into the picture.
Most enterprise access incidents in the last few years didn't come from sophisticated zero-days. They came from a misconfigured IAM role, a long-lived access key sitting in a repo, or a VPN account belonging to a contractor who left eight months ago.
According to the 2024 Verizon DBIR stolen credentials appear in roughly 31% of breaches over the past decade, and the IBM Cost of a Data Breach Report has been flagging stolen or compromised credentials as the most common initial access vector for years running.
It's not that there's a lack of access control products. The problem is that most of these were designed for a world where the perimeter was a building, not a control plane scattered across AWS, Azure, GCP, a few SaaS apps, and whatever a developer just spun up in a sandbox account.
Cloud-native access control is the response to that shift, and picking the right vendor has gotten genuinely hard.
This guide is a working framework for that decision. It covers what cloud-native access control actually means, the capabilities you should expect on the shortlist, how to evaluate vendors against your own environment, and a selection process that won't leave you stuck mid-rollout.
What "cloud-native access control" actually means
Cloud-native access control is a category of platforms that govern who and what can reach resources across cloud infrastructure, SaaS, and private networks, using identity and context as the primary control rather than network location.
A few things are worth pulling apart in that definition.
Identity-first, not network-first
Legacy access control assumes "inside the network" means "trusted." Cloud-native access control assumes nothing about location. Every request is authenticated and authorized against an identity, a device, and a policy, regardless of whether the request originated from a corporate office or a coffee shop.
Resource-scoped, not subnet-scoped
Instead of granting access to a 10.0.0.0/16 range and hoping for the best, a cloud-native platform grants access to a specific resource (a database, an API endpoint, an internal app) for a specific identity.
Continuous, not session-based
Authorization decisions are made on every request, not once at session start. If a device's posture changes mid-session or a user is offboarded in the IdP, access can be revoked immediately.
This is what people usually mean when they say Zero Trust Network Access (ZTNA), and it's also the through-line for adjacent categories: Cloud Infrastructure Entitlement Management (CIEM), Cloud Security Posture Management (CSPM), and Identity-Aware Proxies (IAP).
How it differs from perimeter-based models
Dimension | Perimeter-based (VPN, firewall ACLs) | Cloud-native access control |
|---|---|---|
Trust model | Implicit trust inside the network | No implicit trust; every request verified |
Access scope | Network segment or subnet | Specific resource or workload |
Identity binding | Loose; often shared service accounts | Tight; bound to IdP user and device |
Exposed surface | Inbound ports, public VPN gateways | Outbound-only connections, no inbound exposure |
Policy enforcement point | Network edge | Closer to the resource, often inline |
Visibility | Flow logs, perimeter telemetry | Per-request, per-identity audit logs |
The perimeter model isn't broken because firewalls stopped working. It's broken because most resources you care about aren't behind a single perimeter anymore.
Why this matters now
Three pressures are pushing access control off the perimeter and into identity.
Misconfiguration is the dominant failure mode
Gartner has been saying for years that through 2025, 99% of cloud security failures will be the customer's fault, and the underlying pattern is consistent: a bucket left public, a security group opened to 0.0.0.0/0 "just for testing," an IAM role with * on the actions.
Cloud-native access control platforms address this by replacing implicit network access with explicit, identity-bound policies that are harder to fat-finger.
Standing privilege accumulates
A typical enterprise user touches dozens of cloud accounts, SaaS apps, and internal services. CIEM research from Sysdig, Wiz, and others consistently finds that over 90% of granted cloud permissions go unused. Every unused permission is a potential lateral movement path.
Lateral movement is the actual blast radius
Once an attacker has a foothold, perimeter-based networks let them move laterally with little friction. Microsoft's analysis of the 2023 Midnight Blizzard intrusion showed exactly this: an OAuth app abuse that pivoted across tenants because trust relationships were too broad. ZTNA, microsegmentation, and least-privilege enforcement are what shrink the blast radius.
If your current access stack can't answer the question "what exactly can this identity reach right now, and from which device?" you have a cloud-native access control problem.
The evaluation framework
A serious shortlist should cover six categories. Score vendors against each, weighted by what your environment actually looks like.
1. Platform features
The capability surface varies widely across vendors. At minimum, ask:
Zero Trust Network Access (ZTNA): Identity- and device-aware access to private resources without exposing them to the internet. This is the load-bearing capability for most enterprise use cases.
CIEM: Visibility into who can do what across cloud accounts, with the ability to flag and right-size over-privileged identities, including non-human identities.
CSPM: Continuous evaluation of cloud resource configuration against benchmarks (CIS, NIST, PCI). Useful to have unified; not always a dealbreaker if you already have it.
Unified visibility: A single audit and policy view across cloud, SaaS, and private network access. Federated dashboards across three tools is not the same thing.
IaC scanning: Catching misconfigurations in Terraform, CloudFormation, or Pulumi before they reach production. Increasingly table stakes.
Device posture checks: Verifying OS version, disk encryption, EDR status, and MDM enrollment before granting access. This is what closes the "compromised laptop with valid credentials" gap.
Session-level controls: Recording, just-in-time elevation, and the ability to terminate sessions mid-stream.
Be honest about what you actually need versus what looks good in a feature matrix. CIEM and CSPM are often handled by adjacent tools (Wiz, Orca, Prisma Cloud), and trying to consolidate everything into one platform sometimes means accepting the worst tool in each category.
2. Integration requirements
Access control is only as good as the systems it plugs into.
Identity provider: SCIM-based provisioning, SAML and OIDC support, and group-based policy assignment against Okta, Entra ID, Google Workspace, JumpCloud, or whatever you run. If you have more than one IdP (common after acquisitions), confirm multi-IdP support.
CI/CD: API-driven configuration so access policies can be defined in code and managed by the same pipelines as the rest of your infrastructure. Terraform providers and Pulumi support matter here.
SIEM and observability: Streaming audit logs to Splunk, Datadog, Sumo Logic, or whatever you use for detection. Pull-based daily exports are not enough for incident response.
MDM and EDR: Pulling device posture signals from Jamf, Intune, Kandji, CrowdStrike, or SentinelOne to inform access decisions.
Secrets and PAM: Coexistence with HashiCorp Vault, AWS Secrets Manager, CyberArk, or Teleport, depending on what you're using for privileged access today.
Anything that requires a custom integration or a professional services engagement should be flagged as a risk.
3. Multi-cloud and hybrid support
A surprising number of "cloud-native" vendors are quietly cloud-specific. Ask:
Does the platform run identically across AWS, Azure, GCP, and on-prem?
How are private resources in different VPCs, subscriptions, or data centers reached? Is there a connector or gateway component, and what does its failure mode look like?
Are there latency or throughput differences depending on region?
How does the platform handle resources behind NAT, in air-gapped environments, or in customer-managed Kubernetes clusters?
For most enterprises, the answer needs to include "hybrid" for at least the next five years. Don't accept a roadmap commitment in place of a shipping capability.
4. Zero Trust alignment
Zero Trust is a model, not a product, but you can test how seriously a vendor takes it by asking:
Are connections to private resources outbound-only from your network, or do they require inbound firewall rules?
Is every request verified independently, or is trust established once at session start?
Are authorization decisions enforced at the resource (or close to it), or at a centralized gateway?
Are policies expressed in terms of identities and resources, or in terms of IP addresses and ports?
What happens to active sessions when a user is removed from a group in the IdP?
A platform that requires opening inbound ports, uses long-lived sessions, or expresses policy in CIDR ranges is not doing Zero Trust, regardless of marketing.
5. Performance and scalability
ZTNA platforms sit in the data path. They will be blamed for every slow query and dropped video call until proven innocent.
Throughput and latency: Request published benchmarks and run your own. Pay attention to behavior under sustained load, not just burst.
Peer-to-peer vs relayed traffic: Architectures that establish direct connections between client and resource (with relays as fallback) generally outperform always-relayed architectures.
Geographic distribution: Where are the relays and points of presence? A user in Singapore connecting to a resource in Frankfurt via a relay in Virginia is going to have a bad day.
Failure isolation: When the vendor's control plane goes down, do existing sessions stay up? Twingate's architecture, for example, separates the control plane (the Controller) from the data plane, which is why customer traffic kept flowing during a notable AWS us-east-1 incident in 2023 even though parts of the broader internet didn't.
Client footprint: Resource consumption, battery impact on mobile, support for the OSes and architectures your fleet actually uses (including Linux and ARM).
6. Commercial considerations
The category is competitive enough that you should expect:
Per-user pricing with clear tiering: Per-resource or per-connector pricing tends to penalize the patterns you actually want (lots of small, narrowly scoped resources).
A free or low-cost tier for evaluation: Anyone serious about a PoC will give you something usable for a real test.
A proof of concept that mirrors production: A two-week PoC with a real workload, real users, and real integrations tells you more than a six-week feature checklist exercise.
Support SLAs that match your operational profile: 24/7 support with named TAMs at the enterprise tier is reasonable to expect.
A clear deprecation and version support policy: Especially for the client and connector components. Twingate, for example, publishes a 12-month rolling support window for clients, which makes patch planning predictable.
Where ZTNA fits, specifically
Cloud-native access control is the umbrella. ZTNA is the specific layer that handles access to private resources: internal apps, dev environments, production databases, SSH targets, Kubernetes APIs, on-prem systems.
For most enterprises, ZTNA is the first thing to fix because it's where VPNs have been failing for the longest. The pattern that works:
Identity-aware: every connection is bound to an authenticated user and a known device, with the IdP as the source of truth.
Resource-scoped: users get access to specific resources, not network segments.
Outbound-only: connectors deployed in your environment make outbound connections to the control plane. No inbound firewall rules, no exposed ports, no public VPN gateway to scan and exploit.
Continuous: every request is verified against current policy, current group membership, and current device posture.
Audited: per-request logs streamed to your SIEM, attributable to a specific user and device.
This is the model Twingate is built around. Connectors sit behind your firewall and dial out to the Controller. Clients on user devices intercept traffic for defined resources, request authorization, and establish a tunnel to a Connector. The Connector independently verifies the request against its own copy of the ACL before proxying to the resource.
No single component compromise grants unauthorized access, and there is nothing to expose to the public internet.
The practical result for an IT or security team: VPN concentrators come out, contractor accounts stop being a quarterly cleanup project, audit logs become useful for actual investigations, and the user experience stops being a recurring help desk ticket.
A selection process that works
Here's the sequence I'd recommend running, in order.
1. Inventory what you're protecting: Before you talk to a vendor, list the resources users actually need to reach: internal apps, databases, SSH targets, Kubernetes clusters, third-party SaaS via private link, on-prem systems. Group them by sensitivity. This list becomes your scoring rubric.
2. Inventory who needs access: Employees, contractors, vendors, service accounts, CI runners, AI agents. Map each group to the resources they touch. This will surface uncomfortable findings (it always does) before any vendor demo.
3. Define the integration surface: IdP, MDM, EDR, SIEM, secrets manager, IaC tooling. Anything a vendor can't integrate with cleanly is a long-term tax.
4. Build a 5-criterion shortlist: Use the framework above to score 3 to 4 vendors. Don't shortlist 10; you'll never run real PoCs.
5. Run real PoCs, not feature demos: Pick one moderately complex use case (say, replacing VPN access for a production environment for a 20-person team) and run it end to end with each finalist. Insist on:
Real IdP integration with your actual IdP
Real device posture checks against your actual MDM
Real audit log streaming to your actual SIEM
Real users, not just the security team
6. Test failure modes. What happens when the vendor's control plane is unavailable? What happens when a Connector dies? What happens when a user's device fails posture mid-session? What happens when you remove a user from a group in the IdP?
7. Validate commercials. Get pricing in writing, including overages, premium support tiers, and renewal mechanics. Confirm the contract terms for data residency, audit rights, and termination.
8. Stage the deployment. Pick one team or one resource group. Roll out, gather feedback, expand. Trying to cut over the whole organization in one weekend is how you end up reinstalling the VPN.
9. Decommission what you replaced. This is the step that gets skipped. If the VPN concentrator is still running six months after the ZTNA rollout, you didn't reduce attack surface, you added another control. Set a hard date and enforce it.
Closing
For more detail on how Twingate's architecture handles identity, device posture, outbound-only connectivity, and audit logging, the Twingate documentation is the best place to start. The Security Policies and Connectors sections are particularly relevant if you're working through the evaluation framework above.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
The Definitive Guide to Choosing a Cloud-Native Access Control Vendor
Andrew Baumbach
•
Product Marketing Engineer
•
A practical buyer's framework for evaluating cloud-native access control platforms, covering must-have features, integration requirements, Zero Trust alignment, and a step-by-step selection process. Start with the Twingate documentation if you want to see how a ZTNA layer fits into the picture.
Most enterprise access incidents in the last few years didn't come from sophisticated zero-days. They came from a misconfigured IAM role, a long-lived access key sitting in a repo, or a VPN account belonging to a contractor who left eight months ago.
According to the 2024 Verizon DBIR stolen credentials appear in roughly 31% of breaches over the past decade, and the IBM Cost of a Data Breach Report has been flagging stolen or compromised credentials as the most common initial access vector for years running.
It's not that there's a lack of access control products. The problem is that most of these were designed for a world where the perimeter was a building, not a control plane scattered across AWS, Azure, GCP, a few SaaS apps, and whatever a developer just spun up in a sandbox account.
Cloud-native access control is the response to that shift, and picking the right vendor has gotten genuinely hard.
This guide is a working framework for that decision. It covers what cloud-native access control actually means, the capabilities you should expect on the shortlist, how to evaluate vendors against your own environment, and a selection process that won't leave you stuck mid-rollout.
What "cloud-native access control" actually means
Cloud-native access control is a category of platforms that govern who and what can reach resources across cloud infrastructure, SaaS, and private networks, using identity and context as the primary control rather than network location.
A few things are worth pulling apart in that definition.
Identity-first, not network-first
Legacy access control assumes "inside the network" means "trusted." Cloud-native access control assumes nothing about location. Every request is authenticated and authorized against an identity, a device, and a policy, regardless of whether the request originated from a corporate office or a coffee shop.
Resource-scoped, not subnet-scoped
Instead of granting access to a 10.0.0.0/16 range and hoping for the best, a cloud-native platform grants access to a specific resource (a database, an API endpoint, an internal app) for a specific identity.
Continuous, not session-based
Authorization decisions are made on every request, not once at session start. If a device's posture changes mid-session or a user is offboarded in the IdP, access can be revoked immediately.
This is what people usually mean when they say Zero Trust Network Access (ZTNA), and it's also the through-line for adjacent categories: Cloud Infrastructure Entitlement Management (CIEM), Cloud Security Posture Management (CSPM), and Identity-Aware Proxies (IAP).
How it differs from perimeter-based models
Dimension | Perimeter-based (VPN, firewall ACLs) | Cloud-native access control |
|---|---|---|
Trust model | Implicit trust inside the network | No implicit trust; every request verified |
Access scope | Network segment or subnet | Specific resource or workload |
Identity binding | Loose; often shared service accounts | Tight; bound to IdP user and device |
Exposed surface | Inbound ports, public VPN gateways | Outbound-only connections, no inbound exposure |
Policy enforcement point | Network edge | Closer to the resource, often inline |
Visibility | Flow logs, perimeter telemetry | Per-request, per-identity audit logs |
The perimeter model isn't broken because firewalls stopped working. It's broken because most resources you care about aren't behind a single perimeter anymore.
Why this matters now
Three pressures are pushing access control off the perimeter and into identity.
Misconfiguration is the dominant failure mode
Gartner has been saying for years that through 2025, 99% of cloud security failures will be the customer's fault, and the underlying pattern is consistent: a bucket left public, a security group opened to 0.0.0.0/0 "just for testing," an IAM role with * on the actions.
Cloud-native access control platforms address this by replacing implicit network access with explicit, identity-bound policies that are harder to fat-finger.
Standing privilege accumulates
A typical enterprise user touches dozens of cloud accounts, SaaS apps, and internal services. CIEM research from Sysdig, Wiz, and others consistently finds that over 90% of granted cloud permissions go unused. Every unused permission is a potential lateral movement path.
Lateral movement is the actual blast radius
Once an attacker has a foothold, perimeter-based networks let them move laterally with little friction. Microsoft's analysis of the 2023 Midnight Blizzard intrusion showed exactly this: an OAuth app abuse that pivoted across tenants because trust relationships were too broad. ZTNA, microsegmentation, and least-privilege enforcement are what shrink the blast radius.
If your current access stack can't answer the question "what exactly can this identity reach right now, and from which device?" you have a cloud-native access control problem.
The evaluation framework
A serious shortlist should cover six categories. Score vendors against each, weighted by what your environment actually looks like.
1. Platform features
The capability surface varies widely across vendors. At minimum, ask:
Zero Trust Network Access (ZTNA): Identity- and device-aware access to private resources without exposing them to the internet. This is the load-bearing capability for most enterprise use cases.
CIEM: Visibility into who can do what across cloud accounts, with the ability to flag and right-size over-privileged identities, including non-human identities.
CSPM: Continuous evaluation of cloud resource configuration against benchmarks (CIS, NIST, PCI). Useful to have unified; not always a dealbreaker if you already have it.
Unified visibility: A single audit and policy view across cloud, SaaS, and private network access. Federated dashboards across three tools is not the same thing.
IaC scanning: Catching misconfigurations in Terraform, CloudFormation, or Pulumi before they reach production. Increasingly table stakes.
Device posture checks: Verifying OS version, disk encryption, EDR status, and MDM enrollment before granting access. This is what closes the "compromised laptop with valid credentials" gap.
Session-level controls: Recording, just-in-time elevation, and the ability to terminate sessions mid-stream.
Be honest about what you actually need versus what looks good in a feature matrix. CIEM and CSPM are often handled by adjacent tools (Wiz, Orca, Prisma Cloud), and trying to consolidate everything into one platform sometimes means accepting the worst tool in each category.
2. Integration requirements
Access control is only as good as the systems it plugs into.
Identity provider: SCIM-based provisioning, SAML and OIDC support, and group-based policy assignment against Okta, Entra ID, Google Workspace, JumpCloud, or whatever you run. If you have more than one IdP (common after acquisitions), confirm multi-IdP support.
CI/CD: API-driven configuration so access policies can be defined in code and managed by the same pipelines as the rest of your infrastructure. Terraform providers and Pulumi support matter here.
SIEM and observability: Streaming audit logs to Splunk, Datadog, Sumo Logic, or whatever you use for detection. Pull-based daily exports are not enough for incident response.
MDM and EDR: Pulling device posture signals from Jamf, Intune, Kandji, CrowdStrike, or SentinelOne to inform access decisions.
Secrets and PAM: Coexistence with HashiCorp Vault, AWS Secrets Manager, CyberArk, or Teleport, depending on what you're using for privileged access today.
Anything that requires a custom integration or a professional services engagement should be flagged as a risk.
3. Multi-cloud and hybrid support
A surprising number of "cloud-native" vendors are quietly cloud-specific. Ask:
Does the platform run identically across AWS, Azure, GCP, and on-prem?
How are private resources in different VPCs, subscriptions, or data centers reached? Is there a connector or gateway component, and what does its failure mode look like?
Are there latency or throughput differences depending on region?
How does the platform handle resources behind NAT, in air-gapped environments, or in customer-managed Kubernetes clusters?
For most enterprises, the answer needs to include "hybrid" for at least the next five years. Don't accept a roadmap commitment in place of a shipping capability.
4. Zero Trust alignment
Zero Trust is a model, not a product, but you can test how seriously a vendor takes it by asking:
Are connections to private resources outbound-only from your network, or do they require inbound firewall rules?
Is every request verified independently, or is trust established once at session start?
Are authorization decisions enforced at the resource (or close to it), or at a centralized gateway?
Are policies expressed in terms of identities and resources, or in terms of IP addresses and ports?
What happens to active sessions when a user is removed from a group in the IdP?
A platform that requires opening inbound ports, uses long-lived sessions, or expresses policy in CIDR ranges is not doing Zero Trust, regardless of marketing.
5. Performance and scalability
ZTNA platforms sit in the data path. They will be blamed for every slow query and dropped video call until proven innocent.
Throughput and latency: Request published benchmarks and run your own. Pay attention to behavior under sustained load, not just burst.
Peer-to-peer vs relayed traffic: Architectures that establish direct connections between client and resource (with relays as fallback) generally outperform always-relayed architectures.
Geographic distribution: Where are the relays and points of presence? A user in Singapore connecting to a resource in Frankfurt via a relay in Virginia is going to have a bad day.
Failure isolation: When the vendor's control plane goes down, do existing sessions stay up? Twingate's architecture, for example, separates the control plane (the Controller) from the data plane, which is why customer traffic kept flowing during a notable AWS us-east-1 incident in 2023 even though parts of the broader internet didn't.
Client footprint: Resource consumption, battery impact on mobile, support for the OSes and architectures your fleet actually uses (including Linux and ARM).
6. Commercial considerations
The category is competitive enough that you should expect:
Per-user pricing with clear tiering: Per-resource or per-connector pricing tends to penalize the patterns you actually want (lots of small, narrowly scoped resources).
A free or low-cost tier for evaluation: Anyone serious about a PoC will give you something usable for a real test.
A proof of concept that mirrors production: A two-week PoC with a real workload, real users, and real integrations tells you more than a six-week feature checklist exercise.
Support SLAs that match your operational profile: 24/7 support with named TAMs at the enterprise tier is reasonable to expect.
A clear deprecation and version support policy: Especially for the client and connector components. Twingate, for example, publishes a 12-month rolling support window for clients, which makes patch planning predictable.
Where ZTNA fits, specifically
Cloud-native access control is the umbrella. ZTNA is the specific layer that handles access to private resources: internal apps, dev environments, production databases, SSH targets, Kubernetes APIs, on-prem systems.
For most enterprises, ZTNA is the first thing to fix because it's where VPNs have been failing for the longest. The pattern that works:
Identity-aware: every connection is bound to an authenticated user and a known device, with the IdP as the source of truth.
Resource-scoped: users get access to specific resources, not network segments.
Outbound-only: connectors deployed in your environment make outbound connections to the control plane. No inbound firewall rules, no exposed ports, no public VPN gateway to scan and exploit.
Continuous: every request is verified against current policy, current group membership, and current device posture.
Audited: per-request logs streamed to your SIEM, attributable to a specific user and device.
This is the model Twingate is built around. Connectors sit behind your firewall and dial out to the Controller. Clients on user devices intercept traffic for defined resources, request authorization, and establish a tunnel to a Connector. The Connector independently verifies the request against its own copy of the ACL before proxying to the resource.
No single component compromise grants unauthorized access, and there is nothing to expose to the public internet.
The practical result for an IT or security team: VPN concentrators come out, contractor accounts stop being a quarterly cleanup project, audit logs become useful for actual investigations, and the user experience stops being a recurring help desk ticket.
A selection process that works
Here's the sequence I'd recommend running, in order.
1. Inventory what you're protecting: Before you talk to a vendor, list the resources users actually need to reach: internal apps, databases, SSH targets, Kubernetes clusters, third-party SaaS via private link, on-prem systems. Group them by sensitivity. This list becomes your scoring rubric.
2. Inventory who needs access: Employees, contractors, vendors, service accounts, CI runners, AI agents. Map each group to the resources they touch. This will surface uncomfortable findings (it always does) before any vendor demo.
3. Define the integration surface: IdP, MDM, EDR, SIEM, secrets manager, IaC tooling. Anything a vendor can't integrate with cleanly is a long-term tax.
4. Build a 5-criterion shortlist: Use the framework above to score 3 to 4 vendors. Don't shortlist 10; you'll never run real PoCs.
5. Run real PoCs, not feature demos: Pick one moderately complex use case (say, replacing VPN access for a production environment for a 20-person team) and run it end to end with each finalist. Insist on:
Real IdP integration with your actual IdP
Real device posture checks against your actual MDM
Real audit log streaming to your actual SIEM
Real users, not just the security team
6. Test failure modes. What happens when the vendor's control plane is unavailable? What happens when a Connector dies? What happens when a user's device fails posture mid-session? What happens when you remove a user from a group in the IdP?
7. Validate commercials. Get pricing in writing, including overages, premium support tiers, and renewal mechanics. Confirm the contract terms for data residency, audit rights, and termination.
8. Stage the deployment. Pick one team or one resource group. Roll out, gather feedback, expand. Trying to cut over the whole organization in one weekend is how you end up reinstalling the VPN.
9. Decommission what you replaced. This is the step that gets skipped. If the VPN concentrator is still running six months after the ZTNA rollout, you didn't reduce attack surface, you added another control. Set a hard date and enforce it.
Closing
For more detail on how Twingate's architecture handles identity, device posture, outbound-only connectivity, and audit logging, the Twingate documentation is the best place to start. The Security Policies and Connectors sections are particularly relevant if you're working through the evaluation framework above.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Solutions
Solutions
The VPN replacement your workforce will love.
Solutions