Okta is an independent identity and access management platform. It holds one profile per person in its Universal Directory, grants access through groups, provisions and deprovisions connected applications through Lifecycle Management, and handles single sign-on and multi-factor authentication. It is vendor-neutral by design, which is why it is common in mixed application landscapes.

Does Key2XS replace Okta?

No. Key2XS is middleware. Okta remains your identity platform and each key system remains your locking system. Key2XS carries decisions from the first to the second and writes the result back.

Which key systems can Okta govern through Key2XS?

iLOQ S5 and S50, ASSA ABLOY eCLIQ, PROTEC2 CLIQ, CLIQ Remote and ABLOY PULSE. A single Okta group can span several of them at once, and Key2XS is certified by ASSA ABLOY for its locking system integrations.

We use Okta group rules to assign access. Does that work for keys?

Yes. Key2XS reads group memberships from Okta regardless of how they are populated. If a group rule adds a user to a mapped group, the corresponding key rights follow automatically.

What happens when we deactivate a user in Okta?

Key2XS withdraws the person's key rights in real-time as part of the same flow, across every connected key system. Physical and digital access are revoked together, and the revocation is logged.

Does anything need to be installed in our Okta org?

No. Key2XS connects through the Okta REST API with an API token and subscribes to Event Hooks. There is no agent and no change to your existing application integrations.

How long does implementation take?

A standard integration is live in under two hours. Key2XS connects to Okta and to the key systems through pre-built connectors, so no custom development is required.

Is this suitable for NIS2 and CER compliance?

Yes. Both directives require governed, auditable control over physical access to premises. Key2XS provides the policy enforcement and audit trail that connects your Okta lifecycle to physical keys.

Okta Integration | Physical Access Governance

What Okta is

Okta is an independent identity provider. Where other identity platforms arrive as part of a wider software stack, Okta was built to sit above all of them, which is why it turns up in landscapes that mix Microsoft, Google, AWS and a long tail of SaaS. Its workforce product governs employees and contractors; its customer identity product, Auth0, governs the people outside your organization.

The parts that matter for access decisions:

Universal Directory. One profile per person, aggregated from HR systems, directories and applications, with a schema you control.
Groups and group rules. Access is granted through groups, and group rules populate them automatically from profile attributes such as department, location or contract type.
Lifecycle Management. Provisioning and deprovisioning across connected applications, driven by the state of the profile.
Single sign-on and adaptive MFA. One authentication event, evaluated against device, network and risk signals.
Okta Workflows. No-code automation for the steps that fall between systems.
APIs and Event Hooks. A REST surface over everything, plus webhooks that fire on lifecycle events as they happen.

Okta's premise is that identity is the control point. Physical keys are the part of the estate that premise has never reached.

Every app is behind Okta. The building is not.

Organizations choose Okta to make identity the control point: one dashboard, one lifecycle, one place where onboarding grants everything and offboarding removes everything. That promise holds for hundreds of applications. Physical keys break it. They are handed out at a desk, registered in a separate key management tool or a spreadsheet, and returned whenever someone remembers.

Offboarding flows that end at software, leaving doors open
Maintenance contractors whose Okta access expired but whose keys did not
No connection between a person's Okta profile and the keys they hold
Physical access audits assembled by hand, location by location

Under NIS2 and the CER Directive, critical entities are expected to govern access to premises with the same discipline as access to systems. The gap between Okta and your keys is precisely where that expectation bites.

How Key2XS connects to Okta

Key2XS reads users, groups and lifecycle states from the Okta API and subscribes to Event Hooks so that lifecycle events arrive as they happen rather than on a schedule. Nothing needs to be installed in your Okta org beyond an API integration.

ProtocolOkta REST API with Okta Event Hooks

AuthenticationOAuth with API token

DirectionBidirectional: identities in, provisioning status back

SynchronizationReal-time, driven by Event Hooks

Connect, map, orchestrate, prove

Connect. Key2XS connects to your Okta org over its REST API and to each key system over its own API. A standard integration is live in under two hours, with no custom development.
Map. Okta groups are mapped to key rights and lock groups. A group like “Maintenance, Depot North” can correspond to exactly the depots, cabinets and technical spaces those crews need, and nothing else.
Orchestrate. When a user enters or leaves a mapped group, or is deactivated or suspended in Okta, Key2XS applies the change to their key rights in real-time. If your groups are populated by Okta group rules, physical access follows those rules automatically.
Prove. Every key right traces back to an Okta identity, a group and a moment in time, in one tamper-evident audit trail.

What moves between Okta and Key2XS

From Okta	To your key systems via Key2XS
Users (joiners, movers, leavers)	Key holders created, updated or deactivated
Group memberships, including those set by group rules	Key rights and access to lock groups
Deactivation and suspension	Immediate withdrawal of key rights
Assignment history	Documented authorization behind every key

One source of truth, every key system

The point of connecting Okta to Key2XS is not a single lock brand. Okta becomes the one place where physical access is decided, and Key2XS carries that decision to whichever key systems your sites actually run. Most organizations have more than one: a digital locking system at the head office, electronic keys on the network, mechanical high-security cylinders on the perimeter.

Key system under governance	How Key2XS drives it
iLOQ S5 and S50 Self-powered digital cylinders (S5) and Bluetooth/NFC phone keys (S50).	REST API. Key holders, key rights and key validity provisioned per person, with 29 independent sync operations.
ASSA ABLOY eCLIQ Electronic cylinders, padlocks and programmable keys.	SOAP API through CLIQ Web Manager, secured with mutual TLS. Full lifecycle, event-driven and batch.
ASSA ABLOY PROTEC² CLIQ High-security locking combining rotating disc technology with electronic identification.	SOAP API through CLIQ Web Manager, secured with mutual TLS. Full lifecycle, event-driven and batch.
ASSA ABLOY CLIQ Remote Remote key updates through wall programmers, desktop units or the CLIQ Connect Bluetooth app, so keys never have to come back to a desk.	SOAP API through CLIQ Web Manager, secured with mutual TLS. Validity windows refreshed in the field.
ABLOY PULSE Self-sustaining locks that harvest their energy from key insertion. No batteries, no wiring.	SOAP API through CLIQ Web Manager, secured with mutual TLS. Full lifecycle, event-driven and batch.

Key2XS is certified by ASSA ABLOY for its locking system integrations. One mapping in Okta can therefore span brands: a single role or group grants the iLOQ cylinders in one building and the eCLIQ padlocks on a remote site, revoked together the moment Okta says so.

The same holds on the identity side. Key2XS also connects to SailPoint Identity Security Cloud, Microsoft Entra ID, One Identity Manager and OpenText Identity Manager, and to any system that can speak SCIM 2.0, so a landscape with more than one identity platform still resolves to one physical access model. See the integrations overview for the full picture.

Built for critical environments

Key2XS is used where physical access affects public safety, service continuity or regulatory compliance: utilities, government, transport, healthcare and industry.

NIS2 and CER ready. A continuous, tamper-evident audit trail links every physical access right to an identity and a policy decision.
Built for continuity. The Key2XS platform is engineered for 99.99% availability, matching the uptime expectations of critical infrastructure operations.
Security by design. Traffic between Key2XS, Okta and every connected key system is encrypted in transit with TLS 1.3, and data at rest is protected with AES-256.
Non-disruptive. Key2XS orchestrates rights through each system's own management interface. Your Okta configuration stays as it is, and so do your locking plans, locks and keys.

Why not script this with the Okta API?

Okta has excellent APIs and automation hooks, and the key systems have APIs too. But a homegrown bridge means owning connector code against several evolving platforms, building your own audit layer, covering every lifecycle edge case, and maintaining it for years while it quietly becomes critical infrastructure. Key2XS delivers this as a maintained platform:

Live in under 2 hours. A standard Okta integration is up and running in under two hours, not weeks or months
Maintained connectors that absorb API changes on the identity side and on every key system
Purpose-built audit and reporting for physical access governance
Certified by ASSA ABLOY for its locking system integrations, and a certified SailPoint Technology Alliance Partner on the IAM side
One platform across identity platforms and key system brands, so your architecture is not locked to a single vendor pairing

Okta and Key2XS: neutral identity, governed physical access