OpenText Identity Manager is an enterprise identity management platform with a long history. It was built by Novell, carried forward as NetIQ Identity Manager, moved to Micro Focus, and became part of OpenText when OpenText acquired Micro Focus in 2023. Organizations running it have often built their identity landscape around it for a decade or more, and the architecture reflects that: it is an integration engine as much as a directory.
The parts that matter for access decisions:
The engine is designed so that everything connected stays in step. Physical keys have simply never been one of the connected things.
The event-driven engine keeps directories, HR systems and applications synchronized, and when something changes at the source, every connected system follows. Physical keys are the exception. They are managed in a separate key administration, issued by a different department, and untouched by the events that govern everything else.
Under NIS2 and the CER Directive, critical entities must govern access to premises with the same rigor as access to information systems. An identity architecture that stops at the digital boundary leaves that requirement unmet.
Key2XS connects through the SCIM 2.0 universal server rather than a bespoke driver. Identity Manager treats it as one more standards-based endpoint, which means no new driver to develop, no change to the Identity Vault schema, and no re-architecture of what already works.
| From OpenText Identity Manager | To your key systems via Key2XS |
|---|---|
| Identities (joiners, movers, leavers) | Key holders created, updated or deactivated |
| Role and resource assignments | Key rights and access to lock groups |
| Deactivations and contract end dates | Immediate withdrawal of key rights |
| Assignment history | Documented authorization behind every key |
The point of connecting Identity Manager to Key2XS is not a single lock brand. Identity Manager 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 PROTEC2 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 Identity Manager 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 Identity Manager says so.
The same holds on the identity side. Key2XS also connects to SailPoint Identity Security Cloud, SailPoint, Microsoft Entra ID, Okta and One 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.
Key2XS is used where physical access affects public safety, service continuity or regulatory compliance: utilities, government, transport, healthcare and industry.
The driver model makes custom connections possible in principle, and a locking system is just another endpoint. In practice a homegrown bridge means specialized development against an API per key system brand, an audit layer you design yourself, and years of maintenance across upgrades on every side. Key2XS delivers this as a maintained platform:
