Disk encryption for workplace devices: policies and recovery keys

Why encrypt disks and where access is most often lost

Disk encryption on workplace devices solves a simple problem: if a laptop is stolen, lost in transit or decommissioned, the data inside must not become accessible to outsiders. This is especially important when a device holds personal data, financial documents, correspondence, credentials to internal systems and project files.

Encryption has a downside: with poor organization you can lose access even for your own company. The goal is not just “turn on encryption”, but to ensure access can be restored quickly, securely and only according to rules.

Problems most often appear in typical situations: a device goes into repair, and after a board or drive replacement the system asks for a recovery key; an employee forgets a PIN or enters it incorrectly several times; a PC was reinstalled or “cleaned” without checking where the key was stored; a device was handed to someone else without a proper procedure; there was a dismissal or sudden role change and the business needs access but no one has the key.

“Without losing access” means there are preassigned responsible parties and a clear request path: who verifies the user’s identity, who is authorized to issue the key, where the issuance is recorded and how fast it happens. For example, an accountant on a business trip received a replacement laptop that already had encryption enabled. IT must be able to restore access to the workstation according to the rules, without sending keys via messengers or keeping paper notes in a closet.

Before rollout, agree rules with at least four stakeholders: InfoSec (threat model and key issuance rules), IT (support, repairs, device inventory), legal/compliance (personal data, retention periods) and the business (critical roles and acceptable downtime).

If the company uses standard corporate PCs and has a service network (for example, supply and support from GSE.kz), preagreed repair and replacement processes significantly reduce the number of painful cases for users.

Basic concepts: disk, TPM, PIN and recovery key

“Disk encryption on workplace devices” usually means full disk encryption (FDE). It protects all data on the drive, including system files, temporary folders and deleted but not yet overwritten fragments. This differs from file or folder encryption, where protection applies only to selected items and the rest of the disk may remain readable.

TPM (Trusted Platform Module) is a chip (or platform feature) that helps securely store cryptographic secrets and verify that the computer booted “as usual.” If the check passes, the disk unlocks automatically and the user often does not notice that encryption is enabled.

PIN, password and recovery key are different things:

• PIN: a short code to unlock at startup; adds protection if the device is stolen.
• User password: used to sign in to the account, but does not always control disk unlocking.
• Recovery key: a long one‑time code for when normal unlocking fails.

A recovery key is needed when the system detects “suspicious” changes. Typical causes are a motherboard replacement, BIOS/UEFI reset or update, Secure Boot setting changes, or moving the drive to another PC. In such cases encryption usually isn’t “broken,” but a verification mode is triggered and the device requests the key to confirm that the disk is being opened legitimately.

What to encrypt first depends on the risk of loss and value of the data. Usually start with laptops and tablets that leave the office; workstations containing personal or financial data; removable media if files are shared; and admin machines or users with access to critical systems.

After that, the discussion is less about technology and more about policies: how PINs are issued, where recovery keys are stored and who may request them.

Choosing an approach and tools without vendor lock‑in

Choose an approach based on how your devices and support are organized, not product names. Requirements are essentially the same for laptops, all‑in‑ones and desktops: data must be protected and access recovery must be manageable.

Differences are usually in risks and pain points. Laptops are lost more often, so they typically require stricter modes (for example, preboot checks). Desktops and all‑in‑ones are repaired and reinstalled more frequently, so clear procedures for replacement and key issuance matter more.

Built‑in OS tools and management via MDM

In many cases the OS’s built‑in features are sufficient. They can encrypt the system drive, work with hardware protection (for example, BitLocker and TPM in Windows) and support centralized settings via MDM or group policies. This is a good choice if you have standard workplaces and are ready to standardize settings: PIN, boot mode, and recovery requirements.

In mixed environments (Windows, macOS, Linux) you often end up with a model where “each OS encrypts its own way,” and a single set of rules and controls is provided by an MDM or endpoint management system: it enforces policies, collects statuses and assists with recovery.

When a separate centralized product is needed

A separate product or extended platform is useful when you have many branches, frequent repairs, high turnover of equipment or strict audit requirements. For example, during mass replacement of workstations it’s important that identity verification and key issuance follow the same process everywhere.

When choosing, focus on practical criteria:

• Policy management: how quickly rules and exceptions can be changed and applied.
• Reporting and compliance: can you see which disks are actually encrypted and when they were checked.
• Recovery: where recovery keys are stored, who can issue them and whether actions are logged.
• Support: clear Service Desk scenarios for repair, board replacement and OS reinstall.
• Compatibility: support for different PC models and operating systems without manual workarounds.

How to describe policies: who, what, when and rules

An encryption policy should answer four questions: who it applies to, what exactly is encrypted, when encryption is enabled and which rules are mandatory. The clearer you write this, the fewer failures and “unexpected” lockouts there will be.

Start with scope. In many organizations it’s simpler and safer to adopt “encrypt all workstations.” If that’s currently infeasible, the minimal set usually includes laptops, managers’ PCs and devices with access to personal data. The wording should be unambiguous: “disk encryption on workplace devices is mandatory for the following device and user groups.”

Then define a short set of mandatory parameters:

• Which drives are encrypted: system, data, or both.
• When to enable: on issuance of a new PC, at first setup, after an OS update.
• Sign‑in requirements: TPM, PIN, password or a combination.
• Can enabling be deferred and for how long (for example, until end of day).
• How exceptions are documented and who approves them.

Specify PIN/password requirements. Not only length matters, but also banning trivial combinations (1234, birth dates) and reasonable rotation rules. A common mistake is too‑frequent changes, which leads users to write PINs on sticky notes. Better to require less frequent, controlled changes and lock after several failed attempts.

Special modes are needed for nonstandard workplaces. In a classroom or at a nurse’s station a shared PC is used across shifts and policy should allow quick access while defining ownership, admin roles and activity logging. In such cases document the device owner, the administrator and how actions are recorded.

Don’t forget removable media. If you allow USB sticks and external drives, keep rules simple: encryption always required or only when taken outside perimeter; can unencrypted media be read; who may approve exceptions; and rules for media belonging to contractors or patients/students.

Example: in a hospital, doctors’ laptops are encrypted on issuance with no deferral and PIN minimum of 8 characters. For a nurse’s station with a shared PC, login via shift accounts is allowed and there is a separate temporary access procedure for outages.

Recovery key storage: where to keep keys and whom to give them to

Recovery keys must belong to the company, not the user. An employee can forget a password, resign or lose a note. IT and InfoSec must have a guaranteed way to restore access without bypassing rules or “breaking into” company devices. This is critical for mass rollouts of workplace disk encryption.

Store keys so they can be found in minutes but cannot be viewed without cause. Common approaches, often combined, include: account catalog (linking the key to the device and owner), MDM or device management system (convenient for laptops and remote staff), a separate protected vault with roles and auditing, and an offline safe for emergencies (sealed envelopes or an encrypted medium in a safe).

Access to keys should be limited and verifiable. A working rule: IT sees the key only on request and only for a specific device, while InfoSec can review issuances and perform spot checks.

To make issuance safe, formalize a procedure:

• verify requester identity according to corporate rules;
• verify right to the device (owner, department, role);
• record reason, time and responsible person in the log;
• issue the key only through an approved channel;
• revoke temporary access after the incident is closed.

Have a fallback plan if domain, MDM or network are unavailable (for example, during travel or outage). An offline copy helps, but its storage must be strictly controlled.

Retention of keys usually equals device life plus an audit period (for example, 6–12 months). Link the key to inventory number, serial number and model. If an SSD is replaced in an office PC, the key will change and the old record should remain in history so incidents or repairs can be traced, including service work on devices supplied by GSE.kz.

Step‑by‑step implementation plan: pilot, scaling, control

Treat encryption rollout as a small project. The goal: enable disk encryption on workplace devices so users barely notice changes and IT does not get flooded with lockouts.

1) Pilot: a small but “right” group

Run the pilot on 20–50 devices from different scenarios: office, remote work, travel, and PCs with heavy applications. Include 1–2 support staff so they experience the user path and immediately see process gaps.

Success criteria should be measurable: percent of successful enables, time to readiness, no loss of access, number of support requests and root causes.

Before launch, check compatibility: TPM presence and health, boot mode (e.g. UEFI), updates, drivers and absence of conflicts with disk utilities. Old OS images and nonstandard BIOS settings often surface here.

2) Unified policies and clear communication

Keep policies in a single place and maintain a template; document differences as exceptions (for example, for a lab department). Users should be told what will change in plain terms: possible PIN prompt at startup, what to do if the device asks for a recovery key, and where to contact support.

A short announcement and a Service Desk cheat sheet usually reduce support requests in the first days.

3) Scale and control without spikes

A practical rollout sequence:

• New PCs and laptops: encryption enabled out of the box in the standard image.
• Then the existing fleet in waves: by branch or department, no more than 5–10% per week.
• A separate wave for remote employees with clear instructions and a support window.
• Regular status checks and reports: encrypted, pending, or error states.
• Analyze failure causes and refine the base image.

Have a rollback plan ready. For example, if a driver update causes mass failures, pause new enables, list affected devices and provide support per procedure. Rollback must be controlled: who decides, for how long, and how to reapply the policy later.

Practical example: when replacing a batch of office PCs (including new workstations), enable encryption on a test delivery, verify successful boot and recovery, then start the main wave.

Compliance checks: how to make sure everything is actually encrypted

Applying a policy is not enough. It’s important to regularly confirm that encryption is really working, recovery keys are saved, and protection hasn’t been left suspended after updates or repairs.

Agree on statuses to appear in reports and tickets. Common statuses are:

• Encrypted (protection active, recovery key registered)
• In progress (encryption underway, estimated completion time available)
• Error (encryption failed to start or stopped)
• Suspended (protection temporarily disabled, needs controlled reactivation)
• Unsupported (e.g. incompatible configuration or missing module)

Collect reports from existing tools: MDM, group policies, inventory scripts. Consolidate data into a device registry: model, owner, status, last check date, and recovery key saved flag. This helps especially with mixed fleets.

Set realistic remediation windows. Noncompliance is usually an “Error” or “Suspended” status beyond an allowed timeframe or missing a confirmed recovery key. Reasonable SLA: 24 hours for critical roles (finance, access to personal data) and 3–5 business days for others.

Check more often than you think: daily summaries for IT on duty and weekly reports for InfoSec. Reports must include not just percentages but concrete device lists and responsible owners.

If you find noncompliance, predefine a clear scenario: auto‑fix (restart encryption, resume from “suspended”, reapply policy), a support ticket with a checklist (power, free space, errors, reboot) or temporary access restrictions to sensitive systems until protection is restored.

Example: after a motherboard replacement a device status becomes “Suspended.” If the rule is “48 hours to restore,” the system creates a ticket, assigns an engineer and the device owner receives a short note explaining what will happen and why.

User support: typical requests and secure recovery

Support makes half of the encryption rollout successful. If users struggle to restore access, they will try to bypass rules. Prepare a simple first‑line script and clear rules for issuing keys.

First‑line script: what to ask before requesting a key

Before requesting a recovery key, understand what happened and avoid confusing this with a normal boot failure.

Check the minimum: who the user is and which device (name, department, inventory or serial number); what is shown on screen (PIN prompt, recovery key prompt, too many attempts message); what changed before the issue (updates, BIOS changes, repair); where the device is (office, home, transit) and whether it’s connected; any signs of theft or loss (then treat as an incident, not a recovery request).

Typical cases are threefold: the user forgot the PIN or has keyboard layout issues; too many wrong attempts triggered recovery mode; or after a firmware update or security setting change the key is requested even though the PIN is entered correctly.

How to issue a key securely

A key must not be “just read out.” You need identity verification and a logged record: requester, device, reason, issuer, method and time. A practical approach is to require two independent verifications (e.g. corporate call plus inventory check).

Remotely you can help with layout and correct PIN input, and issue a key in a controlled manner if the device is with the user. On‑site repair or service intake is required when the PC won’t boot, components were replaced, or the device is already in a workshop. If a workstation is in service, give the key only to an authorized company employee, not to a technician over the phone, and record it in the ticket.

A short user checklist reduces lockouts:

• don’t change BIOS/UEFI settings without IT approval;
• don’t disable TPM or “reset security”;
• inform support before repair or board replacement;
• if a recovery screen appears, don’t guess the code — contact support immediately;
• store PINs in a secure manager, not on sticky notes.

Repair and replacement: how to avoid data loss and keep keys secret

Repairs and hardware replacement often break the “transparent” access to an encrypted drive. The main risk: after a change in hardware (especially the motherboard) TPM considers the device “different” and requests the recovery key. Policy should describe in advance what to do so disk encryption on workplace devices doesn’t turn into downtime or an incident.

A motherboard replacement almost always causes new TPM measurements. If protection relies on TPM (for example BitLocker + TPM), the system may require the recovery key at first boot. That’s secure, but bad if the key isn’t at hand or issuance is uncontrolled.

Procedure before repair

Good practice: every repair starts not with a screwdriver but with a short procedure and a recorded ticket.

• Verify the recovery key is available to IT and matches this device.
• Make an up‑to‑date backup of critical data or confirm data is already in corporate storage.
• If hardware intervention is planned, temporarily suspend protection for the repair (with mandatory reactivation).
• Record serial number, requesting employee, reason and responsible persons.
• If there is a risk of board or firmware replacement, agree a downtime window and a recovery plan.

If a contractor performs repairs, do not give them “extra” access. The contractor usually needs only the device and a description of the fault. The recovery key must remain with IT/InfoSec and be issued only by a verified, ticketed process: identity check, ticket number and reason, one‑time issuance and logged confirmation.

Replacement and decommissioning

When replacing a PC, the goal is safe data transfer and a clean closure of residuals. Migrate data via trusted channels (corporate storage, managed migration). Enable encryption on the new device immediately and verify the recovery key is stored properly.

Decommissioning and disposal require verifiable data destruction. At minimum, keep an archive entry: disposal or destruction act; confirmation of cryptographic wipe or physical destruction; a note that the device’s recovery keys are no longer valid; and a transfer log (chain of custody).

If you use manufacturer devices with a local service network, contractually define who can power on devices, who communicates with service, and that the service never receives recovery keys under any circumstances.

Common mistakes that make encryption a problem

Disk encryption on workplace devices typically “breaks” not because of the technology but due to organizational oversights. Initially everything looks fine: policy applied, reports green, users quiet. Then a repair, reinstall or board swap happens and suddenly no one knows where the key is or who may issue it.

Mistakes that lead to loss of access

The most dangerous habit is storing recovery keys “however it happens.” If keys are in a spreadsheet on a shared drive or sent by email, you create both leakage risk and loss risk: the file can disappear, access can be removed and the action history is unrecoverable.

Second common mistake: enabling encryption without a pilot and without a tested recovery scenario. A pilot tests the “bad day” not the encryption speed: what will the user see, what will support tell them, how quickly is the key found and who verifies identity.

Third problem: overly broad key access. If “just in case” many IT staff can view keys, they become ordinary passwords. Define roles clearly: who can request, who can issue and who approves.

Fourth mistake: forgetting about repair and replacement. Example: after a motherboard swap BitLocker asks for a key at first boot. If service engineers, warehouse and support act ad hoc, you waste time or force the user to find a photo of a key in a messenger.

Fifth: not checking the actual encryption state. A policy may have been applied, but the disk could be suspended, partially encrypted or unprotected due to an old BIOS or TPM settings.

To reduce such cases, keep basic rules:

• keys stored centrally and issued only on request with identity checks;
• pilot is mandatory to practice PIN loss, board replacement and OS reinstall scenarios;
• minimal access to keys and logged actions;
• repair and replacement procedures include a step “check encryption and TPM status”;
• reports reflect the disk’s actual state, not only “policy applied.”

If you procure and lifecycle PCs with an integrator or manufacturer (including GSE.kz), agree a unified procedure in advance: who requests a key at what stage, who verifies identity and where it is documented.

Quick checklist and next steps for IT and InfoSec

Before a full rollout, ensure disk encryption on workplace devices won’t become a series of lockouts and urgent key requests.

Checklist before full fleet rollout

Verify these items in the pilot group before expanding scope:

• Clear list of devices to encrypt first and allowed exceptions.
• Central storage for recovery keys and assigned roles: who requests and who issues.
• Rules for special cases: BIOS/UEFI updates, motherboard replacement, drive transfer, repair.
• Support team trained on recovery scenarios with ready reply templates.
• Regular reporting: which devices are encrypted, which are not, and why.

Checklist for issuing a recovery key

Issuing a key is a controlled procedure. Before issuance record at minimum:

• who requests and how identity was verified (corporate account, call, ticket);
• device serial or inventory number;
• reason for the request (repair, update, forgot PIN);
• to whom and when the key was issued, who issued it and the ticket number;
• result: device booted, key rotated or rotation scheduled.

Monitor simple metrics so you know the process works: percentage of encrypted devices, number of key requests per week, and average resolution time.

Next steps: update IT and InfoSec procedures, give short training to first‑line staff, configure reports and a monthly exception review. When upgrading the fleet, account for TPM compatibility and service requirements. System integration and managed support — for example, from GSE.kz — can help, especially when repairability and lifecycle control are important.