11. Devices, tools, and workplace continuity

The Shock happened on a Friday. Over the weekend, the leadership team focused on infrastructure, data, and communication. By Sunday evening, the CTO had sent an update through the emergency channel: core systems were being stabilized, and the team should plan to be in the office Monday morning for coordinated recovery.

On Monday, the first problem was getting in. The entrance doors and turnstiles had defaulted to fire safety mode: open, unlocked. The access control system required a cloud connection to authenticate badges, and without it, the hardware had fallen back to its emergency setting: let everyone through. For the first few hours, this felt like a minor nuisance - but by midday, with “unsolicited visitors” wandering into the building’s cafeteria, it felt like a liability. The office manager called a security company. A guard arrived by Tuesday. The daily rate was painful.

Inside, every screen in the building: the welcome displays in the entrance hall, the menu board in the cafeteria… All of them ran a lightweight display app that someone had vibe-coded on a US-hosted platform some time ago. It had taken an afternoon to build, worked beautifully, and no one had thought about it since. Now every screen in the company was a monument to a dependency no one had mapped. Even the freaking coffee machines were dead: their cashless terminals needed a server connection to validate badge payments. No cloud, no coffee.

At 14:23 on Tuesday, exactly 96 hours after the Shock, every corporate phone locked simultaneously. The MDM grace period had expired. For four days, the devices had continued to operate normally, quietly counting down, waiting for a management server that would never respond. When the timer ran out, the policy did exactly what it was designed to do: wipe the device. 

Failure modes

Previous chapters addressed infrastructure, data, identity, and communication. This chapter addresses a more mundane but equally paralysing failure: the inability of employees to perform basic work on the devices in front of them.

Modern workplace environments became deeply cloud-dependent in an incremental shift: a cloud-based office suite replaced a local one, file storage moved from local disks to synced drives, device management moved to a SaaS platform, and physical office systems were connected to the internet for convenience. Each change was individually rational. Together, they created a workplace that cannot function without continuous cloud connectivity.

The failure modes are varied but share a common pattern: systems that work invisibly in normal conditions become hard blockers when the cloud is unavailable.

• Device lockout. Cloud-based device management platforms (Microsoft Intune, Jamf, Kandji) enforce compliance policies by checking in with a central server. When that server is unreachable, devices may refuse to complete boot sequences, lock screens, or re-enroll. Disk encryption keys managed exclusively by the MDM platform become inaccessible, and the hardware becomes physically unusable. 
• Application void. Companies that rely exclusively on cloud-based office suites (Google Workspace, Microsoft 365 Online) discover that when those services are unreachable, employees often lack a local application capable of opening, editing, or even reading documents. 
• File inaccessibility. When file storage is entirely cloud-based (Google Drive, OneDrive, Dropbox) with no local synchronisation or offline cache enabled, employees lose access to every working document simultaneously. Active projects, customer deliverables, internal reports, and reference materials are all behind a login that returns nothing. Even employees who can boot their machines and have local applications installed cannot work, because the files they need do not necessarily live anymore on their devices.
• Collaboration tool blackout. Async coordination tools (Slack, Teams, Notion, Confluence, Jira, Salesforce, Hubspot…) are unreachable. Documentation, project tracking, task assignments, and institutional knowledge disappear. 
• Physical office disruption. Office access systems that depend on cloud-connected badge readers or smart locks may prevent employees from entering the building. VoIP phones that authenticate through cloud services go silent. Printers, meeting room booking systems, and HVAC controls that depend on internet connectivity degrade or stop functioning. The physical workspace itself becomes partially unusable.

Objectives

The objective is to ensure that employees can perform meaningful work on their devices and in their workplace, even during a prolonged loss of cloud access. Specifically, the company must ensure that:

• employees can open, read, and edit documents using locally installed applications,
• critical working files are available on local storage, not exclusively in the cloud,
• a minimal fallback exists for async coordination and knowledge sharing,
• physical office access and critical building systems function without internet.

This chapter does not aim for full workplace redundancy. It aims to ensure that the workforce, physically present and willing to work, is not rendered idle by dependencies that could have been mitigated at minimal cost.

Solutions

Device sovereignty

The "break-glass" principle introduced in Chapter 2 for identity systems applies equally to hardware. Device sovereignty means ensuring that every managed device can start, authenticate a local user, and operate in a degraded but functional mode without phoning home to a cloud-based MDM platform. It requires designing device management policies with an explicit, deliberate failure mode, and understanding the security tradeoffs involved.

Understanding MDM failure behaviour. Not all device management platforms behave the same way when they lose contact with their server. The spectrum ranges from fully permissive (the device continues to operate normally, ignoring the missing server) to fully restrictive (the device locks, quarantines itself, or refuses to boot past a compliance gate). The default behaviour varies by vendor, policy configuration, and enrollment type.