Mobile phones have become part of the operating model of critical infrastructure. Engineers use them to receive work orders, identify assets, activate credentials, report incidents, scan QR codes, access documentation, communicate with control rooms and, increasingly, interact with physical access systems.
That is both good and dangerous.
A mobile phone can make field operations faster, safer and more auditable. But in critical infrastructure, a phone is not just a communication device. It is an endpoint, an identity carrier, a location sensor, an authentication factor, a camera, a messaging platform and sometimes a bridge between IT, OT and physical access. When unmanaged, it becomes a highly concentrated risk.
NIST already treats mobile devices as permanent enterprise endpoints that process sensitive data and access modern networks. Its mobile device security guidance focuses on managed deployment, lifecycle control, policy enforcement, application management and technical countermeasures. That framing is essential for critical infrastructure. A phone used by a field engineer should not be treated like a personal convenience device. It should be treated as part of the operational security architecture.
The strongest argument for mobile phones is operational speed: critical infrastructure is geographically distributed. Energy substations, telecom sites, rail assets, water installations, bridges, tunnels, pumping stations and roadside cabinets are often unmanned. Field teams need real-time instructions, secure access, incident escalation and evidence capture on location.
A well-managed mobile workflow can replace paper instructions, static key lists, manual approval chains and after-the-fact reporting. That is a major governance improvement. Mobile phones also enable just-in-time access. Instead of giving contractors broad physical access for weeks or months, access can be activated for a defined person, a defined asset, a defined window and a defined task. This reduces standing privileges. It also makes revocation faster when an employee leaves, a contractor changes role or a key is reported lost.
ASSA Abloy CLiq Connect
The second strength is identity binding: a phone can combine MFA, device trust, biometrics, location signals and app-based approval flows. This makes it possible to answer a basic but often unresolved question in physical operations: who is allowed to open what, when, why and under whose approval?
The third strength is auditability: mobile workflows can capture access activation, alarm handling, lost key reports, maintenance completion, photos, GPS context and timestamps. For NIS2 and CER-style governance, this matters. ENISA’s 2025 NIS2 technical implementation guidance focuses on risk management measures, evidence, governance and security controls for regulated entities. Mobile operations can support that evidence base, provided the controls are designed properly.
The fourth strength is resilience: during incidents, phones can support out-of-band communication, emergency access, rapid dispatch, field verification and remote coordination. In a crisis, the organization that knows where people are, what they are allowed to do and which assets they can safely access has a material operational advantage.
The biggest weakness is concentration of risk: a mobile phone often combines identity, authentication, communication, operational data and access capability. If compromised, it may provide an attacker with more than a password. It may provide context, location, social graph, credentials, approval channels and operational timing.
The second weakness is device diversity: many critical infrastructure organizations operate with a mix of corporate phones, BYOD, rugged devices, contractor devices and temporary project devices. That creates inconsistent patching, different operating system versions, different security baselines and unclear ownership. In OT-heavy environments, this becomes worse because operational continuity often wins over lifecycle discipline.
The third weakness is messaging dependency: WhatsApp, SMS, Signal, Teams and email are often used informally to coordinate operational work. That is convenient, but dangerous. Sensitive site information, access instructions, photos of cabinets, key codes, QR codes, alarm procedures and escalation paths may leak into unmanaged channels. Once this happens, governance is gone.
The fourth weakness is phishing and social engineering: mobile screens are small, users are in the field, attention is divided and urgency is common. Attackers exploit exactly that. A technician receiving a fake work order, fake MFA prompt or fake support message while standing near a critical asset is a realistic scenario, not a theoretical one.
The fifth weakness is blurred IT/OT separation: mobile phones often move between office networks, home Wi-Fi, public networks, vehicles, field sites and sometimes local asset interfaces. If a phone is used to interact with OT-adjacent systems, NFC readers, Bluetooth devices, mobile access apps or field diagnostics, it must be governed with much stricter controls.
The sixth weakness is loss and theft: Phones are carried everywhere. They are forgotten in vehicles, dropped at sites, handed to colleagues, repaired by third parties and sometimes shared in practice. If local data, app sessions, cached credentials or offline access rights are not tightly controlled, the risk is obvious.
The core problem is not the phone itself. The core problem is governance.
Many organizations introduce mobile apps into critical infrastructure because the business case is strong. Faster field access. Less paperwork. Lower operational cost. Better user experience. But they fail to define the security operating model around it.
That operating model must answer hard questions:
Who owns the device?
Who manages the device?
Which apps are allowed?
Which identities can use the app?
Which assets can be accessed?
How long is access valid?
What happens when the phone is offline?
What happens when the phone is lost?
What evidence is logged?
Which events go to the SOC?
Who approves emergency access?
How are contractors removed?
How is physical access reconciled with IAM and IGA?
Without these answers, mobile phones create a shadow access layer.
For critical infrastructure, mobile use should be built around a managed trust model.
iLOQ S50
First, every operational phone should be enrolled in mobile device management or equivalent endpoint governance. Unsupported operating systems, rooted devices, unmanaged devices and unknown devices should not be allowed to access operational functions. NIST’s mobile security guidance explicitly promotes managed deployment, security policy enforcement and lifecycle control as core elements of enterprise mobile security.
Second, mobile access should be identity-driven. The phone should not be the source of authority. IAM or IGA should be the source of truth. The mobile app should enforce policies that are already approved through identity governance.
Third, access should be just-in-time and task-based. Permanent mobile-enabled access to critical sites is a bad default. Rights should be activated for a specific person, role, object, time window and operational reason.
Fourth, local storage must be minimized. The phone should not become a database of sensitive infrastructure information. Offline capability may be necessary, but it must be explicitly designed, encrypted, time-limited and auditable.
Fifth, mobile workflows must feed the SOC and audit process. Lost phone, failed activation, unusual location, repeated denied access, emergency override, alarm disablement and access outside working hours are not app events. They are security events.
Sixth, contractors must be governed as first-class risk objects. Critical infrastructure depends heavily on third parties. A contractor with a mobile app and physical access capability is not “external” from a risk perspective. That user is inside the operational trust boundary.
For physical access, the biggest mistake is to see the mobile phone as a replacement for the key. It is not. The phone should become a controlled activation and governance channel. The electronic key, cylinder, lock system, IAM platform and mobile app must operate as one governed workflow. That means access rights are not manually distributed, not stored forever and not hidden in a local lock system. They are connected to identity, role, approval, policy and audit.
This is especially relevant for electronic key systems such as ASSA ABLOY CLIQ and iLOQ. These systems are powerful in distributed environments because they can operate where online door readers are impractical. But the governance gap appears when key rights, user roles and organizational changes are managed separately. Mobile phones can close that gap, but only when they are part of an identity-driven architecture.
In that model, the mobile phone is useful because it enables activation, verification, emergency handling, lost key reporting and operational feedback. But the authority remains in the governance layer. That is the difference between a secure mobile access architecture and a convenient app with too much power.
For boards and CISOs, the question is not whether mobile phones should be used in critical infrastructure. They already are. The real question is whether they are governed.
If mobile phones are unmanaged, they increase the attack surface. If they are governed properly, they reduce operational friction and improve control. The difference is not technology. The difference is architecture, policy and accountability.
Critical infrastructure organizations should therefore treat mobile phones as strategic control points. They sit at the intersection of identity, physical access, operational resilience and incident response. That makes them too important to leave to informal practice.
Mobile phones are both a strength and a weakness in critical infrastructure. They are a strength when they support just-in-time access, field efficiency, identity verification, incident response and auditability. They are a weakness when they become unmanaged endpoints, informal communication channels, uncontrolled credential carriers or shortcuts around IAM and IGA.
The conclusion is: mobile phones do not belong outside the security model. They belong inside it, fully governed, fully auditable and tightly connected to identity. In critical infrastructure, convenience without governance is not innovation, it is exposure.