Disk encryption on government workstations

Disk encryption for a government agency is not justified by a product name or a key length. A convincing justification connects four things: what data resides on the workstation, which event the measure protects against, who manages the keys, and how the acceptance team will verify the result. If any link is missing, the procurement gets an attractive feature table instead of a manageable security control.

The most common mistake begins with the statement "AES-256 is required." It says nothing about a lost laptop with its key nearby, a computer with suspended protection, an employee who has left, or a motherboard replacement at a district office. The algorithm matters, but recoverability and evidence of actual protection usually decide whether the deployment succeeds.

This article concerns ordinary official information on workstations. State secrets, special networks, and other restricted environments have separate requirements. They cannot automatically be covered by the same terms of reference.

Define the data, environment, and threat first

Selection starts with a short usage model, not a product catalog. The contracting authority describes information categories, device types, work locations, and events in which encryption must preserve confidentiality. A desktop in a guarded room and a laptop used by a district inspector have different conditions, even when both run the same operating system.

Full disk encryption mainly reduces the risk of data being read outside the normal boot process: after device theft, removal of a drive, transfer of an unprepared computer for repair, or incorrect retirement of storage. It does not stop a user who has already signed in, malware running in that session, copying a file to an allowed cloud service, or photographing the screen. The justification should state this boundary plainly. Otherwise, the acceptance team will expect one control to perform the work of DLP, antivirus software, and access control.

For each workstation group, it helps to complete one row in a matrix: data category, drive type, network environment, mobility, likely event, required preboot state, and acceptable recovery time. For example, loss outside the building is the event for a laptop holding internal official documents, and the required outcome is that the drive cannot be read without an approved factor or recovery key.

Resolution No. 832 of the Government of the Republic of Kazakhstan on Unified Requirements separately establishes inventory controls for workstations and storage media using unique identifiers, rules for taking workstations off site, protection of mobile users, and guaranteed destruction of information when media is reused or retired. It also associates restricted official information with workstations on the internal network that have no Internet connection. These rules do not choose a product for the contracting authority, but they define context that must appear in the threat model and technical documentation.

Before publishing the procurement, the information owner, information security unit, and legal counsel should confirm the applicable handling rules for every data category. A reference to a general law alone is unsafe because a special information regime can change the requirements for the tool, certification, key location, and administrator authorization.

Convert each regulatory requirement into a testable property

A regulatory basis works when every requirement is paired with an implementation, evidence, and an acceptance test. The simple formula is: "the cited provision requires X, the tool and process provide Y, and the team verifies Z." This connection is more useful than a long list of regulations with no explanation.

The Unified Requirements under Resolution No. 832 require the organization to document the cryptographic protection tool, cryptographic algorithm and key length, area of use, and configuration. The documentation must also cover generation, secure transfer, storage, use, and destruction of key material, action after compromise, rules for end users, and the list of authorized administrators. For a procurement specialist, this is a ready outline for criteria, but it should not be copied into the terms of reference without parameters from the agency's own environment.

If the chosen tool or activity is subject to mandatory conformity assessment, licensing, or another authorization regime, the contracting authority should require a specific valid document and a way to verify its scope. The word "certified" without a number, term, product version, and covered configuration is not evidence. The same applies to the Register of Trusted Software and Electronic Industry Products: applicability must be determined for the specific procurement and item, while a supplier's presence on a list does not prove every encryption property.

A useful justification table has five columns:

This table explains the procurement to an auditor and gives the acceptance team a working test scenario. If a property cannot be confirmed with a document, command, or test, it is too early to mark it as satisfied.

Full disk encryption does not replace file protection

For a standard workstation, full encryption of the system and fixed volumes is usually the baseline option. It is transparent to applications and prevents data from being read from a removed drive. NIST SP 800-111 distinguishes full disk encryption, volume and virtual disk encryption, and file or folder encryption. The guide recommends choosing the type of protection according to the medium, volume of data, environment, and threats. That is more useful than debating a product before defining the task.

Full encryption has its intended effect while the computer is off, hibernating, or waiting at a preboot check. After a successful sign-in, applications access decrypted data through the operating system. A shared computer with an active session, weak permissions, or an infection therefore remains exposed. Especially sensitive data sets may need separate encrypted containers, file protection, access controls, and transfer controls.

File encryption has a different effect: protection can remain with an individual document when it is copied to an approved location, if the format and key management support that behavior. Such a solution often depends more heavily on applications, file extensions, and user actions. It does not automatically cover the page file, temporary copies, search indexes, and other traces. The terms of reference should define which layer addresses each risk instead of demanding both layers "for extra security" without a scenario.

Removable media needs a separate profile. It has a different life cycle and owner, is more likely to move between systems, and makes central storage of recovery information harder. The policy should either prohibit official data on such media or set a compatible encryption format plus rules for issue, inventory, return, and destruction. The statement "USB encryption is supported" answers none of these questions.

Do not require hardware self-encryption merely because it appears faster. The contracting authority would still need to establish who implemented the cryptography, how the firmware was assessed, where the keys arise, and how the mode is controlled. Software encryption with processor acceleration is often easier to verify and configure consistently across different drive models. Tests and authorization documents should drive the choice, not a marketing label.

Assess the algorithm together with its mode and implementation

The terms of reference should name permitted algorithms, modes, key lengths, and tool versions, but should not turn the number 256 into a score for the entire control. Disk encryption needs a mode designed for sector data. Common Windows implementations use XTS-AES with 128-bit or 256-bit keys. XTS addresses block encryption on storage, but does not by itself authenticate each sector like a network protocol using AEAD. This is an accepted design boundary that must be combined with boot and operating system integrity controls.

Microsoft's BitLocker documentation identifies XTS-AES 128 as the default method for automatic device encryption. It also states that changing the method on an already encrypted drive requires full decryption followed by encryption again. The project consequence is simple: apply the algorithm policy before mass enablement, or correction will require time, free capacity, power, and a fresh period of exposure.

An AES-256-only requirement is popular because a larger number is easy to defend during approval. It does not fix a weak preboot password, a shared help desk account, or a recovery key carried in the same bag as the laptop. If the applicable rules and threat model permit both options, the team should compare platform support, validated implementation, performance impact, update process, and manageability as well as key length.

The contracting authority should request a matrix of supported combinations: operating system and edition, UEFI, Secure Boot, trusted platform module, drive type, algorithm, initial encryption mode, and recovery method. The word "compatible" without an exact version hides most of the risk. The matrix should separately state what occurs after firmware updates, boot order changes, motherboard replacement, and drive migration.

Cryptographic implementation strength is not proven by a user interface demonstration. The evidence should include conformity documents, the cryptographic module version, and descriptions of random number generation and the key life cycle to the extent required by the applicable regime. If the supplier cannot connect a document to the proposed build, the acceptance team should treat that as a break in the evidence chain.

Preboot protection sets the actual boundary

A trusted platform module is useful, but it should not be documented as an automatic substitute for user authentication. In a typical design, the TPM releases the key only when the boot chain is in the expected state. This protects against several types of offline modification and removes the need to keep a key on external media. A stolen computer that starts normally to the sign-in screen still depends on account protection and lockout policy.

Microsoft recommends combining BitLocker with a TPM and describes an additional PIN or startup key as a way to stop normal boot until another factor is presented. An operating system drive can be encrypted without a TPM, but a startup key must then reside on removable media, while the password option lacks preboot integrity verification and is exposed to guessing attacks. For a government agency this is not an automatic prohibition, but it is a reason to demand a separate justification for exceptions.

The workstation profiles should select exact options. A desktop in a controlled zone might use a TPM with account protection if the threat model permits it. A laptop that regularly leaves the building often needs a TPM and preboot PIN. An emergency workstation without a compatible TPM should not silently fall back to a weaker design. It belongs on an exception list with an owner, expiry date, and compensating controls.

Compatibility must be tested on the supplied hardware profile, not on a similar test laptop. UEFI and firmware settings matter for TPM 2.0. A BIOS update or TPM reset can trigger recovery. During the pilot, the team should perform a planned firmware update, change a secure boot setting according to the scenario, and confirm that support staff can see the key identifier, verify the requester, and return the workstation to normal protection.

GSE.kz can account for compatibility among the hardware configuration, system software, and security tools when supplying and integrating workstations. The terms of reference should still define measurable parameters and tests so that the outcome does not depend on the integrator's name.

Keys belong to a process, not an administrator

A recovery key grants access to everything protected by encryption, so its repository is part of the protected system. It should be separate from the workstation, available when the main infrastructure fails, and governed by role-based access. Emailing keys to users or keeping a spreadsheet with one administrator makes recovery quick only until the first disclosure or staff departure.

For each type of key material, document creation, binding to the device and volume, backup, release, usage logging, replacement after exposure, and destruction. The workstation identifier in the asset system must map unambiguously to the volume and recovery key identifiers. A chassis serial number is not enough if the drive has been replaced and the record was not updated.

Roles should at least be separated among the policy owner, recovery operator, and log reviewer. An operator needs access only to keys for the group they support, not to the whole repository. Release takes place after identifying the user and verifying entitlement to the specific device. The log records the requester, operator, device, key identifier, reason, time, and outcome without writing the secret itself in plain text.

In a domain environment, BitLocker information can be saved automatically to Active Directory Domain Services before protection is enabled. Microsoft documentation warns that a recovery password opens the entire volume and recommends central storage apart from the device. AD DS keeps the history of recovery passwords for the computer object, and old records are not deleted automatically. The terms of reference therefore need a successful backup check before activation, restricted read access, rotation rules, and a retention period for obsolete records.

A cloud key repository is acceptable only after a separate decision on location, channels, administrators, and the applicable information regime. A technical feature in a product does not establish that it is lawful in a particular environment. For an isolated network, verify that the complete cycle works without an external service, including initial activation, recovery, auditing, and updates.

When exposure is suspected, the operator should do more than create a new password. The operator records the incident, revokes or removes the old protector under an approved procedure, creates a new one, confirms its backup, and checks the log. Rotation is incomplete if the old secret still opens the volume.

Test recovery before mass encryption

Treat the recovery plan as part of the security control, not as instructions for an unlikely accident. Without it, encryption turns a routine motherboard replacement or failed firmware update into departmental downtime. The acceptance team should see the complete cycle on a test device before the project touches every workstation.

A minimum scenario works as follows:

1. The operator finds the test device by its asset identifier and matches the displayed recovery identifier.
2. The help desk identifies the requester, checks entitlement to the device, and records the reason for the request.
3. An authorized operator retrieves the required secret without exposing other records and transmits it through the approved channel.
4. After access is restored, the administrator removes the cause, replaces a potentially exposed protector, and confirms a new backup.
5. A reviewer matches the ticket, release record, and final protection state, then closes the event.

On Windows, the workstation can be checked with a built-in command. The command below neither enables protection nor changes configuration, so it is suitable for an acceptance report:

manage-bde -status C:

The expected output includes at least Conversion Status, Percentage Encrypted, Encryption Method, Protection Status, Lock Status, and Key Protectors. For an accepted volume, the team should see 100 percent encrypted, the approved method, Protection On, and the agreed set of protectors, such as TPM and a numerical recovery password. Waiting for Activation or suspended protection does not equal a protected drive, even if the interface says the volume is encrypted.

Automate this test for the full sample and retain the result with device name, time, and policy version. A screenshot from one computer does not prove deployment across a thousand workstations. The management system should identify devices with no report, zero percent, an incorrect algorithm, an unknown key, or suspended protection.

The emergency access test should run while the main management channel is unavailable. If keys exist only on the same domain controller that cannot be reached from the emergency segment, a formally backed-up secret does not help. The contracting authority should set a recovery time objective, backup authorization procedure, and responsible on-call roles, then measure the time during an exercise.

A pilot exposes what the product sheet omits

The pilot must reproduce actual hardware and organizational conditions, including a slow district-office connection, different user profiles, and normal repair tasks. Ten identical new computers at headquarters do not show what will happen on an older model, with an unusual application, or for an employee traveling away from the office.

The sample should include every hardware profile, operating system edition, drive type, and authentication option. Test a clean installation, a nearly full drive, an operating system update, a UEFI update, sleep, hibernation, forced power loss, motherboard replacement, and drive migration. Measure initial encryption on external power and battery separately, because the client may defer the operation during user activity or power saving.

Measure performance using agency tasks, not a single synthetic benchmark. An administrative workstation needs acceptable sign-in, opening of large archives, search, and antivirus scanning. An engineering workstation needs its own models and temporary files. Set the acceptance threshold in advance, such as the maximum allowed increase in the time for a named operation, instead of the vague phrase "without noticeable degradation."

Protection state after maintenance deserves special attention. A technician may suspend protection before a firmware update and forget to resume it. The management system should therefore detect suspension, limit its duration, and create an event. The team should deliberately suspend protection on a test device and verify when it appears in the report and who receives the task.

The pilot ends with an exception report, not a supplier presentation. For every failure, record the configuration, reproducibility, impact, remediation owner, and decision on eligibility. An unresolved exception either changes the terms of reference or removes that profile from deployment. Deferring the problem to "operations" almost always means the support team will pay for it later.

The terms of reference define outcomes and boundaries

Good terms of reference do not tie a procurement to one interface, but they also do not hide behind general language. They define scope, mandatory functions, compatibility, management, evidence, and acceptance. A bidder should know what result to deliver, and the acceptance team should be able to reject a result that merely resembles the requirement.

The scope section should include the number and types of workstations, system versions, volume types, network environments, mobility, and exceptions. The cryptography section should state permitted algorithms and modes, key lengths, generation sources, required conformity documents, and the link between each document and version. The preboot section should define TPM, PIN, or other factor options for each profile.

The management section should require a central policy, automatic backup before enablement, role-based access, logging, and exception reporting. For an isolated environment, explicitly prohibit any unapproved dependency on the Internet or a user's personal account. Give removable media either a separate rule set or an explicit prohibition.

The recovery section should define requester verification, lookup by identifier, permitted transmission channel, rotation after exposure, operation during primary system failure, and target time. The supplier should provide administrator and user instructions in the required languages, a role model, a configuration backup, and an exercise program. One file containing 48 digits for each computer is not sufficient.

Acceptance testing should include fewer but more precise checks:

• a removed drive cannot be read on another computer without an approved secret;
• the tool does not activate until the recovery key is stored in the approved repository;
• reporting shows the algorithm, percentage, protectors, and state of every test volume;
• motherboard replacement or a UEFI change causes controlled recovery, after which protection is active again;
• an operator with a limited role can view the required key but not another group's records.

Write rejection criteria alongside them: wrong mode, unregistered key, an unapproved external service dependency, no suspension event, or failure to meet the recovery time. This specificity protects both parties better than the requirement to "provide reliable encryption."

Decide from life-cycle evidence

A weighted matrix can help compare bids, but mandatory conditions should not be converted into points. Applicable authorization, support for the required platform, key storage before activation, and successful recovery should act as eligibility gates. A bidder that fails a mandatory test should not offset that failure with an attractive price or an extra report.

After eligibility, the team can assess total cost, central management quality, support workload, logging coverage, operation in an isolated network, and update consequences. Cost includes licenses, key repository infrastructure, the pilot, training, on-call support, replacement of incompatible hardware, and repeated encryption. An operating system feature can be license-free and still require operational resources, so zero license cost does not mean a free control.

One coherent document is enough for the final justification. It names the information regime and boundaries, lists threats, maps rules to functions, records the chosen algorithms, describes keys and recovery, and attaches pilot results and acceptance criteria. The information owner, information security, IT operations, and procurement unit sign the selection record within their respective authority.

Before announcing the procurement, check the current text of regulations, the status of required documents, and register entries. Rules change, and a copy of a certificate from last year's project does not establish coverage for a new version or scope. This is an operational issue: an assessment will expose the gap between a document and the delivered build.

Encryption should be accepted only after two successful demonstrations: a lost drive does not disclose data, and authorized support restores access within the target time with a complete event record. Everything else, including the algorithm name on the first page of a bid, matters only within that life cycle.