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.

The fundamental design principle

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:

• A verified digital identity
• A current employment or contractor relationship
• An approved role
• A defined operational purpose
• A specific set of assets or locations
• A valid time window
• An accountable approval process
• A complete audit trail

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.

The position of Key2XS in the Enterprise architecture

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:

• Identity and Access Management platforms
• Identity Governance and Administration platforms
• Human Resources systems
• Contractor-management platforms
• Service-management systems
• Asset-management platforms
• Geographic information systems
• Security Operations Centre and SIEM environments

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.

Identity is the starting point

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:

• Employee or contractor status
• Organisational unit
• Job function
• Project assignment
• Region
• Operational team
• Certification status
• Security clearance
• Contract start and end dates
• Line manager
• Cost centre
• Emergency role

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.

From business role to physical permission

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.

Role-based access

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.

Attribute-based access

In an Attribute-Based Access Control model, the decision is based on a combination of attributes. Access may depend on:

• Function
• Region
• Employer
• Project
• Training status
• Time of day
• Asset classification
• Incident status
• Work order
• Risk level

This enables more precise decisions than a static role alone.

Policy-based access

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.

The Key2XS policy engine

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:

• Activated
• Suspended
• Revalidated
• Escalated
• Recertified
• Revoked
• Converted into temporary access
• Restricted to a defined time window
• Subjected to additional approval

This is where physical access becomes part of enterprise governance rather than a standalone technical administration process.

The connector architecture

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:

• Credential status
• Permission status
• Key activation
• Cylinder events
• Failed transactions
• Synchronisation errors
• Offline events
• Revocation status

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.

A complete provisioning flow

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.

Step 1. Identity registration

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.

Step 2. Access request

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.

Step 3. Policy evaluation

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.

Step 4. Permission translation

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.

Step 5. Provisioning

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.

Step 6. Activation

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.

Step 7. Logging and confirmation

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.

Step 8. Automatic revocation

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.

Joiner, mover and leaver governance

The joiner, mover and leaver process is one of the most important controls in identity governance. Key2XS extends this process to physical access.

Joiner

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.

Mover

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.

Leaver

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.

Just-in-time physical access

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:

• For a specific work order
• For a single shift
• For a defined group of locations
• During an emergency response
• After real-time approval
• Until a specified expiry time

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 mobile operational layer

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:

• Activate or reactivate access rights
• Request ad-hoc access
• Receive temporary permissions
• Report a lost key
• Initiate revocation workflows
• Disable or re-enable an alarm
• View authorised infrastructure locations
• Confirm operational actions
• Support incident handling

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.

Alarm integration

Opening a technical location is often only one part of the operational process. A worker may also need to:

• Disable an alarm
• Confirm arrival
• Perform the authorised task
• Re-enable the alarm
• Confirm departure

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.

Lost keys and compromised credentials

A lost electronic key is an incident, not merely an administrative inconvenience. The organisation must determine:

• Who owned the key
• Which locations it could access
• Whether the access was still active
• When the key was last updated
• Whether the key was used after being reported missing
• Which permissions must be revoked
• Which teams must be informed
• Whether further investigation is required

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.

Audit and evidence

An auditor does not only want to know whether a key exists. The auditor wants to know:

• Who approved the access
• Why the access was required
• Which policy applied
• Which locations were included
• When the access became active
• Whether the permission was used
• Whether exceptions occurred
• Whether the access was reviewed
• When the access was revoked
• Whether revocation was successfully executed

Key2XS creates a chain of evidence across the complete lifecycle. The audit record can combine information from:

• Identity systems
• Approval workflows
• Role assignments
• Policy decisions
• Physical access platforms
• Mobile transactions
• Alarm processes
• Incident workflows
• Revocation actions

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.

Recertification of physical access

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:

• A location
• A region
• A group of assets
• A critical room
• A contractor access package
• An emergency permission
• A privileged physical area

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.

Segregation of duties

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:

• A location is classified as highly critical
• A maintenance activity creates operational risk
• A person has conflicting responsibilities
• A regulatory policy requires dual control
• An emergency override must be independently approved

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.

Artificial intelligence and keyplan optimisation

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:

• Overly broad access profiles
• Historic permissions that are no longer justified
• Duplicate access groups
• Inconsistent regional configurations
• Excessive standing access
• Unused permissions
• Contractor access that outlives the assignment
• Complex keyplans that no one fully understands

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:

• Removing unnecessary permissions
• Consolidating duplicate access groups
• Creating more precise role models
• Replacing standing permissions with just-in-time access
• Identifying abnormal combinations
• Detecting access outside expected patterns
• Suggesting a more manageable keyplan structure
• Highlighting access that requires recertification

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.

Event handling and security operations

Physical access events can provide valuable security intelligence. An unusual event may indicate:

• Use of an expired permission
• Attempted access outside a normal region
• Repeated failed access
• Use of a credential after termination
• Access at an unusual time
• A lost key being presented
• An unexpected combination of physical and digital activity

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.

Compliance by design

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:

• Identity-based access assignment
• Formal approval workflows
• Contractor lifecycle control
• Timely revocation
• Access reviews
• Segregation of duties
• Exception management
• Incident evidence
• Audit reporting
• SIEM and SOC integration
• Policy enforcement across multiple physical access systems

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.

Vendor-neutral governance

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.

SaaS, on-premises and hybrid deployment

Critical infrastructure organisations have different security, sovereignty and availability requirements. Key2XS is designed as a containerised platform that can support multiple deployment models.

SaaS deployment

In a SaaS model, the platform is centrally operated and updated. This supports rapid deployment, scalability and standardised operations.

On-premises deployment

Some organisations require the platform to operate within their own controlled environment. This may apply to highly restricted, isolated or regulated environments.

Hybrid deployment

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.

Containerised platform architecture

The containerised design allows Key2XS components to be deployed, scaled and updated independently. This supports:

• Modular services
• Controlled releases
• Horizontal scaling
• Resilient deployment
• Environment separation
• Automated monitoring
• Repeatable installation
• Integration with modern infrastructure platforms

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.

Security boundaries and responsibilities

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:

• Identity verification in the IAM environment
• Approval and policy evaluation
• Secure API and connector communication
• Controlled provisioning to the locking platform
• Credential activation
• Cryptographic communication between credential and lock
• Event collection
• Audit and incident handling

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.

Exception management

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:

• Defined emergency roles
• Time-limited permissions
• Additional approval
• Mandatory justification
• Elevated logging
• Post-event review
• Automatic expiry
• SOC notification

This allows the organisation to remain operational without normalising uncontrolled access.

Operational visibility

A central governance platform provides management information that is difficult to obtain from isolated locking systems. Key2XS can help organisations answer questions such as:

• How long does physical access provisioning take?
• How quickly is access revoked?
• How many permissions are permanent?
• How many are just-in-time?
• Which contractors still have active access?
• Which access rights have not been used?
• Which users have unusually broad access?
• Which assets have the highest number of authorised users?
• Which revocations have not been completed?
• How many policy exceptions remain open?
• How long does contractor onboarding take?
• Which physical access events contributed to an incident?

These metrics turn physical access into a manageable governance domain. Relevant performance indicators can include:

• Time to provision access
• Time to revoke access
• Percentage of just-in-time permissions
• Number of standing permissions
• Contractor onboarding time
• Audit exceptions
• Exception remediation time
• Access review completion
• Permission hygiene
• Mean time to respond to hybrid incidents

What Key2XS changes

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:

• Identity governance
• Cybersecurity
• Operational resilience
• Contractor management
• Compliance
• Risk management
• Incident response
• Enterprise architecture

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.

One identity. One policy framework. One audit trail.

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.