building zero trust beyond identity

There’s a question every IT admin eventually stops asking out loud because they’ve accepted it has no clean answer.

“Why do I know everything about this device — and almost nothing about who’s actually sitting in front of it right now?”

You’ve got patch status, compliance posture, app inventory, and location. You can wipe it remotely at 2am from your phone. But the person logging in at 9am? That’s still largely a handshake agreement and a password someone probably reused from three other accounts.

That gap is why OneIdP exists. And two years in, here is the honest story of what it took to close it.

The world IT teams were actually living in

The conventional answer was already well-established: buy an IAM tool, bolt it onto your UEM, configure SSO somewhere in between. 

Different vendors, different dashboards, and different places for your policy to quietly contradict itself the moment an edge case walks through the door.

The deeper problem was that enterprise IT environments aren’t built around clean scenarios — they’re built around exceptions. Shared devices, remote onboarding, contractors on personal laptops, and distributed teams across five time zones, to name a few.

These weren’t edge cases to manage around. They were the actual operating conditions.

Yet most access strategies were still written for a world where everyone showed up at the same office, on the same managed device, every single day. So authentication became the proxy for everything. Authentication was being treated as a solved problem. Verify the password, grant the session. Done.

Most access decisions were still being made with only part of the picture. Because knowing who someone is tells you almost nothing about what they’re signing in from. Whether that device has been patched. Whether it belongs to the organization. Whether it’s the enrolled machine from last quarter or a personal laptop in a hotel lobby.

That was the gap we set out to close.

What we shipped on day one — and why it was just the beginning

When OneIdP launched, we made a deliberate choice that most product teams don’t. We shipped a foundation instead of a feature list.

A cloud directory. Conditional access through Keycard. MFA that lived inside the same dashboard IT teams already used every day. The foundation was deliberately solid before it was feature-rich. 

Keycard lets IT teams set real access conditions — approved locations, trusted IP ranges, specific Wi-Fi networks, and time-based windows. For teams running on shared passwords and zero-context logins, even that first version was a different way of working.

Solid ground, before we started building up.

And then something happened that told us the foundation had actually landed. And within months, customers weren’t asking if OneIdP worked. They were already thinking about what came next. 

• How to bring their existing Okta or Entra setup into the picture. 
• How to make access decisions that reflected device compliance, not just identity. 
• How to make it work for shift-based teams sharing machines across a full working day.

That was the map, and we followed it.

Two years of building for that reality

Most identity tools are built around assumptions.

That a valid credential means a safe session. That IT teams will rebuild their directory to fit a new platform. That someone with deep IAM expertise will be available to maintain it all.

These assumptions have been baked into enterprise access management for years, because well, nobody stopped to question them.

We questioned all three.

1. Identity is enough to grant access

SSO, as the industry has always shipped it, stops the moment credentials check out. The user is who they say they are. Session granted.

What it never asked was what’s behind the credential. Whether the device is patched. Whether the request is coming from a location that makes sense. Whether the application being accessed should even be open on that particular machine at that particular moment.

We built Extended Access Policies (XAP) to ask exactly that.

Every login gets evaluated against the full picture. Live device compliance signals from Veltar feed directly into the access decision. If something doesn’t check out, access stops before anything opens. No manual review. No admin intervention. The policy just works.

Then we looked at the other side of the same problem.

On a device that OneIdP already knows and trusts, asking the user to type their password again adds nothing. Just friction that quietly tells the person behind the screen that IT doesn’t trust them. Enhanced SSO on Managed Devices removes that entirely. The device’s compliance status becomes the credential. The experience becomes invisible — in the best possible way.

2. You’ll start fresh with identity

Every “just switch to our platform” pitch has the same blind spot.

It assumes IT teams will walk away from years of directory configuration, IdP integrations, and access policies, and rebuild from scratch inside a new tool. For a team managing 800 devices across two continents, that’s not an easy migration.

Identity Federation was built for that reality.

OneIdP sits as the access policy layer on top of whatever foundation already exists. Entra, Google Workspace, Okta, PingOne, or on-prem Active Directory setups that predate the current IT team — all of it stays in place. 

We took it even further with SCIM Inbound and Outbound. When someone joins, access is provisioned automatically. When their role changes, access adapts. When they leave, accounts are removed without a ticket being raised or a manual step being missed. The workforce representation across every connected application stays accurate.

3. Someone will always be there to run it

The architecture decision is the easy part. Living with the platform is where identity management usually gets complicated.

Local admin passwords are a good example of a problem that sits quietly in the background until it doesn’t. Identical credentials across hundreds of machines, unchanged for months, because rotating them manually is a project nobody has time for. LAPS made that automatic. Rotation happens on schedule. Every credential is audited. The risk disappears without requiring anyone to act on it.

The User Portal gave employees one place to find every sanctioned application. IT-curated, always current, no ambiguity about what’s approved. The kind of thing that doesn’t generate praise but permanently eliminates a specific category of help desk ticket.

Device-Based SSO solved the shared device problem that had been sitting unanswered since launch. Any enrolled user on a managed machine gets their app access. No re-enrollment between shifts. Access follows the person. The device stays ready for whoever is next.

SSO Access Logs gave every CISO the audit trail they asked for in their first security review — automatically, without anyone building it in a spreadsheet.

Three assumptions. Three deliberate decisions to build differently.

But decisions on paper and decisions in production are two very different things.

Here’s how it actually unfolded.

The timeline, honestly

It helps to see how this unfolded — not as a product roadmap, but as a series of responses to what we were learning:

What OneIdP actually looks like today

When we launched, the conversations were about building the right foundation. Getting device trust and identity into the same policy layer. Making conditional access actually reflect what was happening on the endpoint in real time.

Today, the conversations are about what that foundation can carry. Deeper integrations, broader fleet coverage, access policies that stretch further across the infrastructure — because the platform was built to go there.

That progression from foundation to full platform is exactly where we intended to take it.

OneIdP today is where identity, device trust, and access policy get evaluated together — at every single login, in real time, with no gap between the endpoint you manage and the access you control. The device and the person behind it finally live in the same universe of policy.

What we’ve held onto throughout is something that gets tested constantly in product development: “the most sophisticated access platform is only as valuable as the IT team’s ability to actually run it. A lean team managing a distributed fleet shouldn’t need a dedicated IAM engineer to keep things working.”

Every release over the last two years has been held to that — powerful enough for a complex environment, operable enough for the people actually in it.

That balance is what we’re most proud of.

What’s coming

Two years of building alongside IT teams teaches you something useful: the problem is always bigger than the one you just solved.

Device trust led to questions about network access. Network access led to questions about infrastructure. Cloud RADIUS support and identity-based SSH access are the next answers — already in the works, shaped by the same conversations that produced everything above. 

The scope of what zero trust access needs to govern keeps expanding, and we intend to expand with it.