Cherry Simplifies PCI and SOC Compliance with Zero Trust Access

Cherry operates at the intersection of finance and healthcare, where access control and regulatory compliance shape how the company operates day to day. The company offers payment plans for health and wellness providers, and with a team distributed across the US and Turkey, reliable and auditable access to internal systems is both a practical and regulatory requirement.

For Etga Erdem, Sr. DevOps Engineer, that meant managing multiple VPNs for roughly 200 users across product and engineering while keeping pace with the compliance demands of operating in both spaces.

Unfortunately for Etga and his team, the VPNs weren't holding up. Cherry ran Firezone and WireGuard, and both had reliability problems. The team in Turkey dealt with recurring incompatibilities between Firezone and local telecommunications providers. When those issues hit, Etga worked through support tickets while affected users waited to get back online.

“User management and resource management are really important features when you’re managing access for more than 200 people,” Etga said. “VPN tools like Firezone and WireGuard are really basic for a huge company, and you simply cannot manage resources and users effectively with them.”

Without granular permission controls, every user got the same default access, which put Cherry's PCI and SOC compliance directly at risk.

“If by default everyone has the same permissions, that’s a huge problem for us,” Etga said. “I’m a DevOps engineer. I need to connect to a Kubernetes cluster, but someone on the Product team doesn’t. But with these legacy VPN tools, I’m giving him or her the same permissions. That is a security problem.”

The team decided they needed to replace Firezone and WireGuard with something that would solve their performance and reliability issues, and meet their strict security requirements.

Making the move to Twingate

Etga evaluated Tailscale and OpenVPN, but the decision came quickly. The Admin Console made the access control model immediately legible, and the policy toggles showed it could meet their compliance requirements from day one.

Twingate operates on a deny-by-default model: no user can reach a resource unless access has been explicitly granted. That addressed the blanket-access problem Cherry had been dealing with.

Etga recognized that tightening access controls takes more than swapping tools. His team rolled Twingate out to Engineering and Product first, keeping their existing access model in place before gradually refining it.

Twingate’s deny-by-default architecture means that no user can access a resource unless it is specifically granted, a significant contrast to the wide default access of traditional VPNs. 

“We just started by using our existing security model with Twingate,” said Etga. “Over time, we created more granular group and resource mapping. So that was a really easy transition for us.” 

This let them fix reliability problems for end users right away while working through access policy changes deliberately.

“Before Twingate we would get errors every week, but these issues disappeared as soon as we migrated to Twingate,” said Etga.

Benefits

Compliance audits became significantly less involved once the team had a single place to show exactly who could access what.

“Now, when we go through an audit we can just show the Twingate Admin Console. We can easily show exactly who has access to what, we can show Audit Logs.”

Twingate's Audit Logs record every create, delete, edit, and connect event across the account, covering users and groups, devices, resources, connectors, policies, service accounts, and API keys. Admins can export records directly from the Admin Console as JSON for a point-in-time review, or configure continuous sync to an AWS S3 bucket for integration with a SIEM or data pipeline. 

For a team navigating both PCI and SOC requirements, having a consistent, searchable activity record means auditors get what they need without a manual evidence-gathering effort.

End user tickets began to decline rapidly.

“Thanks to Twingate, we don’t have to deal with VPN issues, so we have a lot more space to work on other projects,” said Etga. “For example, we’re using a lot of AI infrastructure to automate repetitive tasks. Because of the time freed up by Twingate, we can work on areas that will free up even more time.”

With fewer access tickets to handle, Etga's team redirected engineering hours toward actual engineering work. That time went into AI infrastructure projects that are now freeing up more time still, a cycle that was incredibly challenging to start when the team was hamstrung with VPN issues.

Looking forward

Migrating to Twingate made other critical security changes easier as well.

"I want to emphasize how easy other transitions are once you're on Twingate," said Etga. "A few weeks ago I made a critical change on the Twingate side: I changed our Google SSO to Okta. It was just one click in Twingate and everything was done. So, our engineers and other end users didn't even notice anything. It was fantastic."

That ease of transition is part of why the team extended Twingate beyond its initial Engineering and Product rollout. Today, Twingate covers the full company.

The team plans to continue tightening their controls by separating AWS clusters into different accounts and deploying additional Twingate Connectors. 

Etga and his team are always excited to explore what’s new from Twingate, and there’s no shortage of capabilities for him to dig into: time-based access restrictions, usage requirements, and application-level controls for SSH and Kubernetes.

For Etga, exploring new capabilities from Twingate strikes the same balance that impressed him from the beginning: tighter security controls that don't translate into more administrative work.