Digital access governance is now a standard enterprise discipline. Employees, contractors and suppliers receive access to applications based on their identity, role, location and responsibilities. Access requests are approved, permissions are reviewed and accounts are automatically disabled when someone leaves the organisation.
Physical access is often managed very differently. Keys are handed out. Access rights are programmed in separate locking platforms. Contractors are maintained in spreadsheets. Changes in employment status do not always reach the physical security environment. Audit information is distributed across identity systems, locking platforms, service-management tools and local operational processes. This creates a structural governance gap.
An organisation may know exactly which applications a person can access, while lacking a complete and current view of which substations, technical rooms, cabinets, tunnels, data centres or operational sites that same person can enter.
Key2XS closes that gap. The Key2XS platform connects digital identity governance with electronic physical access. It acts as an independent orchestration layer between Identity and Access Management, Identity Governance and Administration, operational systems, mobile users and electronic locking technologies.
The result is not simply another lock-management application. It is a governance platform that translates identity, policy and business context into controlled physical access.
Key2XS starts from a simple principle:
Physical access should be governed by the same identity, policy and lifecycle processes as digital access.
A physical key, mobile credential or electronic access token should not be treated as an isolated object. It should be connected to:
Key2XS establishes that connection. The platform does not replace the Identity and Access Management platform. It does not replace the electronic locking system. Instead, it connects these environments and coordinates the decisions and transactions between them. This architecture allows organisations to maintain their existing investments while introducing a central governance model across physical and logical access.
Key2XS operates between several technology domains.
On one side are the systems that know who a person is and why that person requires access. These include:
On the other side are the systems that execute physical access. These include electronic key systems, smart cylinders, mobile credentials, access-control platforms and alarm systems. Key2XS is the policy translation and orchestration layer between these domains.
A typical architecture looks like this:
Identity source → IAM or IGA → Key2XS policy and orchestration layer → electronic locking platform → key, mobile credential or cylinder
The information flow also works in the opposite direction:
Cylinder, key or locking event → locking platform → Key2XS → IAM, audit environment, SIEM, SOC or compliance reporting
This bidirectional model is essential. Governance cannot be based exclusively on issuing access rights. The organisation must also be able to verify what was provisioned, what was used, whether an exception occurred and whether access was correctly revoked.
Every governed access transaction starts with identity. The authoritative identity will normally originate from a corporate directory, HR system, IAM platform or IGA platform. Key2XS connects with identity environments such as SailPoint, Microsoft Entra ID, Okta, One Identity, Omada and OpenText or NetIQ, depending on the organisation’s architecture.
The identity record provides the foundation for the physical access decision. Relevant attributes can include:
Key2XS does not need to become a second identity repository. Its function is to use the required identity attributes and governance decisions to control the downstream physical access process. This is an important architectural distinction. The platform is designed around data minimisation and references to authoritative sources. Identity information remains governed in the systems that own it. Key2XS uses the relevant context to execute and validate physical access transactions.
An IAM platform understands identities, roles, groups and entitlements. An electronic locking system understands keys, doors, cylinders, time schedules and access profiles. These are different data models. The central function of Key2XS is translating between them.
A business role such as “regional high-voltage maintenance engineer” does not directly correspond to a single door permission. It may represent access to hundreds of geographically distributed assets, with different ownership, risk classifications, working hours and approval requirements. Key2XS translates the business role into the required physical access configuration. This translation can use several models.
In a Role-Based Access Control model, physical access is assigned based on an established business role. For example, a maintenance engineer for a defined region may automatically receive access to a standard group of substations and technical locations within that region. When the person changes role, the access package changes accordingly.
In an Attribute-Based Access Control model, the decision is based on a combination of attributes. Access may depend on:
This enables more precise decisions than a static role alone.
Some physical locations require additional controls. Access to a critical control room may require management approval, two-person verification, a valid work order or a limited activation period.
Key2XS applies these policy conditions before the physical access transaction is released to the locking environment. The result is that access is not merely technically possible. It is demonstrably authorised under an established policy.
At the centre of the platform is the policy and orchestration layer. This layer evaluates whether an identity should receive, retain, modify or lose a physical permission. The decision can be based on data from multiple connected systems.
A simplified decision may be expressed as:
Identity is active, role is valid, contractor agreement has not expired, required training is current, access request has been approved and the requested asset falls within the authorised region.
Only when the relevant conditions are met does Key2XS instruct the connected locking platform to issue or update the physical permission. The policy engine also determines when permissions should be:
This is where physical access becomes part of enterprise governance rather than a standalone technical administration process.
Key2XS uses connectors to communicate with identity platforms, operational systems and physical access technologies. These connectors solve a practical enterprise problem. Every platform uses its own data structure, terminology, API behaviour and lifecycle logic.
The connector layer normalises these differences. An IAM connector may receive an approved entitlement assignment. Key2XS then converts that entitlement into the data objects and transactions required by the connected physical access platform.
A physical access connector may return information about:
Key2XS converts these technical events into governance-relevant information that can be consumed by the identity, audit or security environment. This connector architecture allows Key2XS to remain vendor-neutral. An organisation can operate multiple IAM platforms, multiple locking technologies or different physical access systems across countries, subsidiaries and asset classes.
The governance model remains consistent, even when the underlying technology is not.
Consider a contractor who has been assigned to perform maintenance on several critical infrastructure locations.
Without integrated governance, multiple manual steps may be required. The contractor is entered into a local administration. A manager sends an email. A key administrator configures a key. A spreadsheet records the issue date. Someone is expected to remove the access when the assignment ends. Key2XS turns this into a controlled workflow.
The contractor is registered in the authoritative identity or contractor-management environment. The record includes the employer, assignment, responsible manager, start date, end date and relevant qualifications.
Access is requested through the organisation’s IAM, IGA or service-management workflow. The request identifies the required role, assets, region, period or work order.
Key2XS receives the approved request and evaluates the applicable physical access policy. The platform checks whether the contractor is active, whether the assignment is valid and whether all required conditions have been met.
The approved business access is translated into the corresponding physical permissions. This may include a key group, cylinder group, geographic area, access schedule or temporary authorisation.
Key2XS sends the required instruction to the connected electronic locking platform. The locking platform remains responsible for the technical execution within its own security architecture. Key2XS governs the entitlement and coordinates the transaction.
The contractor activates or updates the credential through the applicable process. This can involve a mobile device, programming terminal, key update point or another mechanism supported by the locking technology.
The result is returned to Key2XS. The platform records whether the permission was successfully issued and makes the status available for governance and audit purposes.
When the assignment ends, the contract expires or the identity is disabled, the revocation process is automatically initiated. The same lifecycle that controls digital access now controls physical access.
The joiner, mover and leaver process is one of the most important controls in identity governance. Key2XS extends this process to physical access.
When a person joins the organisation, approved physical access can be provisioned as part of the onboarding workflow. There is no need to create an unrelated parallel process for keys and locations.
When a person changes role, region, project or employer, Key2XS recalculates the required physical permissions. Access that is no longer justified can be removed. New access can be added after the required approval. This prevents permission accumulation, where users retain every physical permission they have received during their career.
When an employee leaves or a contractor’s assignment ends, physical access revocation is triggered by the authoritative identity lifecycle event. This is a critical improvement over manual key-administration processes. The organisation no longer depends exclusively on someone remembering to notify the physical security administrator.
Permanent access is operationally convenient, but it increases risk. A person who has standing access to a large number of critical locations represents a greater exposure than a person whose access is activated only when required. Key2XS supports a just-in-time access model for physical environments.
Under this model, the entitlement may exist in the governance platform, but the usable physical permission is limited to the operational requirement. A maintenance worker may receive access:
Once the operational window closes, the access expires or is revoked. This reduces standing permissions while maintaining operational flexibility. For critical infrastructure, this balance is essential. Security controls cannot prevent engineers and emergency teams from doing their work. They must provide rapid access without creating uncontrolled long-term exposure.
The Key2XS mobile application extends governance into the field. The app is not intended to become an independent source of authority. It is an operational interface to the policies and permissions already governed by Key2XS and the connected identity environment. Depending on the connected systems and configured processes, users can use the app to:
This is particularly relevant for distributed infrastructure. Engineers may work in areas with limited connectivity. Electronic cylinders may also maintain access and event information locally. The architecture must therefore support controlled operations in environments where continuous online communication cannot be guaranteed.
Key2XS coordinates the governance process around these offline-capable technologies. When connectivity becomes available, events and status information can be synchronised into the relevant management and audit environments.
Opening a technical location is often only one part of the operational process. A worker may also need to:
When these actions are managed separately, the organisation lacks a complete operational record. Key2XS can connect physical access and alarm workflows so that they form part of the same governed transaction.
For example, the mobile workflow can determine whether the user is authorised to disable the alarm for a specific location. The action is logged and linked to the identity, location and access event. The system can then support reactivation of the alarm after the work is completed. This creates a more complete chain of accountability than a lock event alone.
A lost electronic key is an incident, not merely an administrative inconvenience. The organisation must determine:
Key2XS links the lost-key process to identity and governance. A user can report the loss through the mobile application or an integrated service-management process. The platform can initiate revocation, identify the associated access rights and create an auditable incident trail.
The response can also be connected to a Security Operations Centre or SIEM platform when the event meets defined risk criteria. This is a major difference between key administration and access governance. Key administration focuses on the object. Governance evaluates the identity, permissions, context, risk and required response.
An auditor does not only want to know whether a key exists. The auditor wants to know:
Key2XS creates a chain of evidence across the complete lifecycle. The audit record can combine information from:
This evidence can support internal audit, external audit, regulatory assessment and incident investigation. It also reduces the operational burden of collecting audit information from multiple independent systems.
Access should not remain valid indefinitely simply because it was once approved. Identity governance platforms already support periodic access reviews for applications and data. Key2XS extends this control to physical locations. Managers, asset owners or security officers can review whether a person still requires access to:
The reviewer is presented with business context rather than a meaningless technical code. This is important. A reviewer cannot make an informed decision when shown only a cylinder number or key profile. Key2XS connects the technical permission to the identity, role, asset and operational purpose. When access is rejected during the review, the revocation can be executed through the connected physical access platform.
Some physical environments require more than one authorised person. A single individual should not always be able to enter, operate or modify a highly sensitive location without additional control. Key2XS can support segregation-of-duties policies and two-person verification scenarios. These controls can be applied when:
The access decision can require two authorised identities, two separate approvals or a combination of role and contextual conditions. This turns a physical security policy into an enforceable digital governance control.
Physical access environments can become extremely complex. Large operators may manage thousands of people, contractors, keys, cylinders, sites and permission combinations. Over time, the access model can become difficult to maintain. Typical problems include:
The Key2XS AI capabilities are designed to assist with this governance problem. The platform can analyse roles, historic assignments, project context, access patterns and existing keyplan structures. Based on that information, it can identify potential improvements. Recommendations may include:
The objective is not uncontrolled autonomous decision-making. Physical access to critical infrastructure requires accountability. AI recommendations should therefore be governed by policy, explainable to administrators and subject to human approval where required. The AI layer supports better decisions. It does not remove ownership of the decision.
Physical access events can provide valuable security intelligence. An unusual event may indicate:
Key2XS can forward relevant events and governance context to SIEM and SOC environments. The advantage is context.
A raw lock event has limited meaning. A governance-enriched event can show that the credential belongs to a contractor whose assignment ended, that the location is classified as critical and that the attempted access occurred outside the authorised work order.
This allows the SOC to prioritise and investigate physical access events as part of the broader cyber and operational security picture. It also supports hybrid incident analysis. An investigator can correlate physical entry, digital authentication, system access and operational actions around the same identity and time period.
Regulations such as NIS2 and the Critical Entities Resilience framework increase expectations around access control, accountability, incident handling, supply-chain security and resilience. Compliance cannot be achieved by producing a policy document alone. The organisation must be able to demonstrate that controls are implemented and operating.
Key2XS supports this by embedding governance controls into the physical access lifecycle. Relevant capabilities include:
The platform can also help expose the gap between policy and execution.
For example, an IAM platform may show that access was revoked, while the downstream locking platform reports that the credential has not yet been updated. Key2XS can identify this difference and escalate it as an operational or compliance exception.
This verification is essential. A governance decision is not complete until it has been successfully implemented.
Many large organisations operate more than one physical access technology. This can be the result of acquisitions, regional procurement, different asset classes or long infrastructure lifecycles. One business unit may use ASSA ABLOY CLIQ. Another may use iLOQ. A third may operate ARX, Aptus or another platform.
Replacing every system is rarely commercially or operationally realistic. Key2XS creates a common governance layer across these technologies. Users and managers do not need to understand the technical structure of every locking system. They interact with roles, policies, locations and business purposes. Key2XS translates these decisions into the relevant downstream technology.
This protects existing investments and avoids creating a new governance silo every time a different locking technology is introduced.
Critical infrastructure organisations have different security, sovereignty and availability requirements. Key2XS is designed as a containerised platform that can support multiple deployment models.
In a SaaS model, the platform is centrally operated and updated. This supports rapid deployment, scalability and standardised operations.
Some organisations require the platform to operate within their own controlled environment. This may apply to highly restricted, isolated or regulated environments.
A hybrid architecture can combine central governance with locally operated components or connectors. This is relevant when physical access systems are distributed across operational networks, local sites or environments with limited external connectivity. The deployment model can therefore be aligned with the organisation’s security architecture instead of forcing the organisation into a single operating model.
The containerised design allows Key2XS components to be deployed, scaled and updated independently. This supports:
The architecture is suitable for cloud-native deployment but is not limited to public cloud environments. This matters for critical infrastructure. Modern software engineering practices must coexist with operational security, network segmentation, availability requirements and long-lived physical systems.
Key2XS governs the access decision and coordinates the transaction. The connected locking platforms remain responsible for the cryptographic operation of their own keys, credentials and cylinders. This separation of responsibilities is deliberate.
Key2XS does not attempt to replace the embedded security model of a certified locking technology. It adds governance, lifecycle control, orchestration, policy enforcement and auditability around that technology. The complete security chain therefore includes:
Security depends on the complete chain. A strong cylinder does not compensate for poor identity governance. A strong IAM platform does not compensate for unmanaged physical keys. Key2XS connects these layers.
Real operations do not always follow the standard process. Emergency crews need immediate access. A network connection may be unavailable. A contractor may need temporary access outside the original work order. A damaged asset may require an urgent intervention. The answer is not to bypass governance. The answer is to govern the exception. Key2XS can support exception workflows with:
This allows the organisation to remain operational without normalising uncontrolled access.
A central governance platform provides management information that is difficult to obtain from isolated locking systems. Key2XS can help organisations answer questions such as:
These metrics turn physical access into a manageable governance domain. Relevant performance indicators can include:
The most important change introduced by Key2XS is not technical. It is organisational. Physical access is no longer treated as a separate administrative activity owned exclusively by local key managers. It becomes part of:
This creates shared accountability. The identity team remains responsible for identity and lifecycle governance. The physical security team remains responsible for physical security policy and locking technology. Asset owners remain responsible for deciding who should access their locations. The SOC remains responsible for security monitoring and response.
Key2XS connects these responsibilities into one controlled process.
Critical infrastructure organisations cannot protect physical and digital access as two unrelated domains. The same identity can authenticate to an application, enter a substation, disable an alarm and access an operational system. The risks are connected, even when the supporting technologies are not. Key2XS provides the orchestration layer required to govern that complete chain.
It connects identity to policy. Policy to physical permission. Physical permission to operational execution. Execution to evidence. That is the inner working of the Key2XS platform. Not another key-management system. A digital governance platform for physical access.
Identity. Policy. Access. Controlled from one platform.