When I talk with IT folks who haven’t discovered Twingate, I sometimes hear:

“If I already have Okta, why do I even need Twingate?”

Okta is a fantastic tool. But it doesn’t get the whole job done on zero trust. An identity platform is necessary, but not enough if you’re looking to roll out and sustain a zero trust security model. It’s a piece of that puzzle, but it’s just that: one piece.

But Twingate and Okta, together? Now that’s a landscape, we can put together: let me paint the picture of this puzzle…

I love Okta (no really, I do)

I’m not just saying that because I work at Twingate, where I’m your friendly neighborhood Sr. IT Admin. I’ve been an Okta evangelist and community leader for years. 

My official Okta bonafides:

• I served as the Okta SF User Group Leader from 2018 - 2020

• I spoke at Oktane in 2017 (scroll about halfway down to see my face)

• My custom SAML insertions were actually integrated into the Okta product. Pretty pleased about that one 😎

Suffice it to say, I like Okta. I mean, we’re an Okta shop here at Twingate! 

As much as I appreciate and advocate for Okta, I also recognize that it’s not all there is to zero trust. It’s because I have such a deep understanding of Okta that I know what it can and can’t do. 

The Favorite Tool Fallacy

Okta can do a lot of really cool things, and it does them well. Not always the case with software vendors, but I digress. 

This is old news, but it’s worth thinking through what Okta does well:

• Authentication

• SSO

• Group and role-based access

Because Okta does these things so well, it can be easy to fall into the favorite tool fallacy:

When your favorite tool is a hammer, every problem looks like nail.

For years, my proverbial “hammer” was PowerShell.

Back before Okta released a PowerShell module CLI interface, I used PowerShell to manage Active Directory and Okta - probably not the most efficient way to do that…

Lots of folks fall into the same habits with Okta, and start applying every possible policy and rule configuration they can think of. You can do that, and it’s great. 

It’s also not enough. 

There’s a hole in your Okta boat, Captain

Okta is a fantastic platform when it comes to addressing the identity pillars of a zero trust model. 

For example, let’s take Rich, our Head of Sales. Okta does a great job of confirming that I know Rich, that I trust Rich, and that I can verify Rich is who he says he is. 

But identity is just one piece of the zero trust puzzle. What if Rich is on a device that should fail your device policy? 

To check for compliance and to ensure that endpoint security measures are in place, you could theoretically craft something yourself, such as manual checks and interventions. But to achieve zero trust you need to be doing this work at scale, constantly. Manual intervention is not the answer here. 

Lots of folks turn to Okta Device Trust to address the need for endpoint posture checks or to check for a managed device. Device Trust really tells you two things:

1. You’ve put a certificate on the device

2. You believe this is a managed device

Establishing the presence of the certificate is insufficient. To put it bluntly: that just doesn’t cut it. 

It’s a static check and lacks real-time enforcement post-authentication. (Zero trust gurus call this “continuous policy enforcement” and it’s kind of a big deal. Unlike traditional “admission-control” security, zero trust approaches grant and maintain access to resources only after ongoing checks.)

If you’re using Okta Device Trust and have a managed device that is infected in some way, those two checks can still remain true. And that means you’ve been compromised, and you don’t even know it yet.

I can hear the protests already: “Not me! I deploy via MDM, so I’ve already covered that gap.”

To which I say: when was the last time you looked at your MDM? 

Your Intune’s of the world typically don’t proactively tell Okta, “Hey, don’t trust this device anymore.”

Even if you use one of Okta’s native integrations with an MDM or EDR tool, you can’t deny access if someone is already authenticated and the interaction is ongoing. 

Consequently, if Rich's device is compromised, Okta is powerless to stop what would be a very bad day for Rich (and me).:

1. At 8:00am Rich authenticates into Salesforce

2. At 11:00am Rich’s device is compromised

3. At 11:01am we’re out of luck

Okta does identity very, very well. But its device attestations (yes, even via integrations) fall short because they’re:

• Static

• Reactive

• And ultimately, risky

The Twingate Puzzle Piece

So, how does Twingate fit into all of this? 

The answer is easy: very, very well. 

Twingate is not an identity provider, and that’s by design. Instead, we integrate with identity providers like Okta to ease administrative burden (groups are automatically synced from Okta, no more duplicate provisioning), and to provide a platform that helps you complete the zero trust puzzle. 

At its core, Twingate zero trust securely connects users to private resources (cloud VPCs, SaaS apps, even the office network), without getting in the way of work for both end users or admins. 

Within Twingate, I can apply lots of different controls to create Resource-specific access policies, including things like:

• Device posture checks (more on that later)

• MFA requirements, even for things like SSH

• Re-authentication rules

• Location requirements

• Auto-revoke policies based on usage or date/time

  
  

In order to connect to a Resource protected behind Twingate, a user must meet the requirements I’ve set. We often think about these access decisions as a big question with lots of component parts:

Should this request associated with this identity within this context complete? And with what privileges and constraints?

What’s worth noting here is that no single Twingate component can independently make a decision to allow traffic to flow to another Twingate component within your remote network. Authorization for access or data flow is always confirmed with a second (or even a third) element of that access question.

That means that if a user or their device fails to meet a policy requirement: no access for you.

Back to the Okta device problem. With Twingate, I can apply a level of device attestation that covers the gaps in Okta without adding complexity for users or admins.

Real-World Defense in Depth

Here's where things get interesting. I work at a software development company (obviously), which means I get an alert in CrowdStrike roughly once a week that causes people to lose access to something.

A developer who is not passing a CrowdStrike check can't get to GitHub. And let me tell you, that gets attention real quick.

Now, CrowdStrike is really good about this stuff. The vast majority of alerts we get are software development false positives, which happens when you're a software company that has a product monitoring and managing network proxy connections (something CrowdStrike views with suspicion).

But when we do get them, it's imperative that we investigate right away. The way our integration is set up means we're not only making sure our systems are CrowdStrike verified, but they're also incident-free. An incident in CrowdStrike means they're not passing Twingate device attestation.

So we work on those very quickly when they come up.

Not All Resources Are Created Equal

Here's another thing Okta can't do that Twingate shines at: different security profiles for different resources.

It's a little bit defense in depth, a little bit zero trust, and a little bit "Jason having fun with his tools" and reducing risk along the way. We put in device policies with different types of profiles for different types of software applications. We don’t complete this zero trust puzzle with an identity hammer.

Some software is very low risk, and we can put very lax requirements. We don't really care if you're 100% CrowdStrike verified on Gmail, for example. We do care that you're 100% CrowdStrike verified on GitHub.

Because of that, we have users who have multiple devices where one device is passing our strictest production security profile, and the other device owned by the same individual is not passing that profile. They can't get access to specific, very highly protected resources on one device, but they can on their other device.

It's a great example of, “we trust that user, we don't trust that device.” The device is failing a specific attestation that we deem appropriate for one of our very important resources, and access is denied accordingly.

Okta's device approach? It's binary. Device Trust or not? Are you trusted, or aren't you trusted? But that's as far as it goes.

The BYOD and Contractor Sweet Spot

There’s another place where Twingate really shines: in unmanaged device environments. 

Twingate can tell if a device has:

• Screen lock enabled

• Firewall enabled

• Hard drive encryption enabled

  
  

… all without MDM enrollment. 

Plus minimum operating system requirements! It may sound a little less shiny, but it’s actually really awesome because of how much legacy is out there. Even in a brand new company that is cloud-native and just formed and moving quickly, chances are you’ve got a contractor or even an employee with a bunch of BYOD devices trying to connect.

That's a super common scenario, especially with contractors. There are a ton of companies out there that don't fully onboard their contractor identities in their HR information systems or in their IdP. In lots of cases they use guest accounts or guest invites, essentially just: "Hey, I'm gonna send a Google invite to this one person to get into this one project."

And they need a hole in their firewall to let them in. That has happened more times in my life than I'd like to count, and Twingate really does help simplify that.

With Twingate we can just say, "Here's your one resource that you have access to. Here's your one rule that gets you there. And here's the minimum requirements of that device in order to get to it." That's very helpful as both a sanity check and security check.

The Ultimate Defense Strategy

Let's talk about what zero trust really means. It's not just about who's logging in - it's about how and from where.

With Twingate and Okta working together, we can layer defenses across:

• All of Okta’s identity 

• Device security posture

• Network-level access routing

• IP-based SaaS restrictions

Here's a real example: you can put very specific IP ranges on Salesforce that say you can only access your Salesforce instance from these IP ranges. That enables you to apply a Twingate zero trust policy to those sessions, too.

So we can say in your Okta environment, you can only authenticate to this resource if you're coming from the Twingate network. In Salesforce, you can say you can only access it if you're coming from a Twingate network.

That's literally two layers. If you somehow manage to steal an authentication token and you're not coming from within the right network, you're not getting in. That's spectacular.

And having that layer of saying, "Yes, we know salespeople can be whiny (sorry Rich, I think you’re great!). We know that they can complain. We know that they don't like jumping through extra hoops. But this is important data. And so these are the things that we put in place to make sure that important data is protected."

It's Not Either/Or

Here's the thing: you don't need to replace Okta. Instead, enhance Okta with Twingate:

• Reduce breach risk

• Strengthen compliance

• Streamline management (Okta makes Twingate better, too)

• Achieve real zero trust

  
  

The truth is, Okta and Twingate work better together. Okta handles identity brilliantly. And Twingate extends zero trust policy application to device and context-aware access.

Okta doesn’t replace Twingate, and Twingate doesn’t replace Okta. Twingate takes one of my favorite tools, and makes it better.

New to Twingate? You can try out Twingate for free or request a personalized demo from our team.