Hardware security in PC procurement: requirement wording

Why include hardware security requirements at all

If a PC procurement does not describe hardware security, you get just “hardware that turns on,” but it may not protect the boot chain, credentials and key settings. Fixing this after delivery is almost always more expensive: procedures change, protective tools are bought, incidents and disputes at operation increase.

In tender documents you usually see two extremes:

• overly general phrases like “high security” or “support for modern protection technologies.” These cannot be verified at acceptance.
• excessive specificity: brand, chip model, “TPM version X.Y from vendor Z.” Such requirements are easy to dispute and often add no practical value.

A practical approach is to describe not “what exactly to buy” but “what the device must do” and “how to confirm it.” Then requirements become verifiable: you know in advance what will be visible in UEFI/BIOS, what the OS will report and which acceptance actions confirm it.

Typically the buyer wants to protect four things: the boot chain, keys and credentials, access to UEFI/BIOS settings, and management of those settings (so IT can apply policies and recover access per procedure).

Imagine a school or a clinic: PCs are in shared rooms and dozens of people have access. Without requirements for Secure Boot and UEFI passwords, one USB stick and a few minutes are enough to try to boot an alternative environment, reset local passwords or disable protections. Well‑crafted requirements do not hinder work but sharply reduce such “quick attacks” and simplify acceptance: either the feature exists and is configurable by policy, or it does not.

Principles for correct tender wording without unnecessary detail

A good hardware security section in a procurement reads as a set of conditions you can check: what must be enabled, how it is checked at acceptance and what proves it. This saves time during negotiations and reduces the risk of receiving a “formally compliant” but impractical solution.

A handy template for each item is the same: requirement — acceptance criteria — supporting document. Then procurement, infosec and IT operations share a common language instead of arguing over interpretations.

Specify function and outcome, not implementation

Excessive detail kills competition and forces bidders to seek workarounds. Instead of “TPM version X of this type only,” describe the outcome: presence of the function, ability to enable it, measurable state and manageability.

A neutral example: “Support for a hardware root of trust to store keys and measure OS boot; the function’s state must be available for inspection in the firmware interface and by OS tools.” This focuses on effect and verifiability rather than internals.

Separate mandatory and desirable

In a tender it’s better to separate what will cause rejection from what is a convenience and can be scored. In practice it’s useful to keep three groups: mandatory requirements, desirable requirements and management requirements (what’s needed for lifecycle: inventory, remote administration, access policy).

Consider who is the administrator and how this will work in the fleet

Wording should reflect operation: who sets policies, where passwords and recovery keys are stored, how settings change when a PC moves between departments, and what happens during repair or board replacement.

A simple operational phrase: “The customer’s administrator must be able to centrally enable and control key security settings, and firmware settings access must be protected by a password with a documented change procedure.” This does not mandate a specific tool but secures manageability.

Ask for confirmations not “by word” but in a clear form: datasheet/specification, a declaration of conformity to the tender requirements and an acceptance checklist with verification steps. If delivery is from a manufacturer or integrator, agree in advance which documents and exports will be attached to the batch. Acceptance will then proceed without surprises.

TPM: example requirements that can actually be checked

Describe TPM in the spec by function and verifiable result rather than brand or model. This reduces the chance that the supplier delivers PCs with the feature disabled in UEFI or inaccessible to the OS.

A baseline requirement for the tender: “The PC must include a Trusted Platform Module TPM version 2.0 (discrete or firmware), supported by UEFI and accessible to the operating system for standard protection mechanisms.”

It is important to record not only presence but state. For example:

• TPM 2.0 can be enabled and initialized via UEFI without special service utilities.
• After delivery TPM is available to the OS and reported as ready for use (Ready/Activated/Enabled or equivalent).
• TPM supports OS-level disk encryption and key protection functions.

To avoid disputes, list acceptance evidence: an inspection act and system information output (screenshots or text report), plus UEFI parameter capture related to TPM. At acceptance it is usually enough to show the UEFI page with TPM settings, the OS system report with TPM status and the execution of a test scenario for disk encryption in verification mode (without requiring full encryption of all devices).

Reasonable boundary: do not require rare lab modes, “internal identifiers” or exact UEFI menu names. Platforms vary and such details rarely affect security, but they create formal grounds for rejection.

If buying a batch for a government body or large organisation, ask to demonstrate TPM enabled and visible in the OS on one sample, and then record in the acceptance act that the same settings were applied to the whole batch.

Secure Boot: correct wording for procurement

Secure Boot ensures a PC boots only through a trusted boot chain. It reduces the risk of boot-time malware and bootloader substitution. For Secure Boot requirements favor expected outcomes and verification signs over firmware internals and key lists.

The verifiable minimum is simple: the function exists, it can be enabled, and when enabled it refuses to boot unsigned components.

Typical accept‑friendly requirements:

• The PC supports UEFI Secure Boot with the ability to enable and disable it in UEFI.
• With Secure Boot enabled the OS boots only when boot components have a valid digital signature.
• Secure Boot is compatible with modern OSes and standard corporate deployment scenarios without constant disabling.
• If corporate images or drivers require adding trusted certificates, there must be a documented key management procedure (who performs it, how it is recorded, how to roll back).

Account for corporate scenarios. Sometimes a custom bootloader, disk encryption agent or signed drivers are used. The goal is not to forbid changes but to ensure manageability: key changes are allowed only via an agreed procedure, with records and the ability to restore the standard key set.

For acceptance request clear evidence:

• a UEFI page showing Secure Boot status (Enabled/Disabled);
• an OS report on Secure Boot state;
• verification that changes are possible only after UEFI admin login;
• note in the acceptance act whether Secure Boot is enabled (if that is the customer policy).

Avoid statements like “keys must never be changed” or “Secure Boot must always be on without exceptions.” Such bans break maintenance and recovery. More practical: enabled by default, changes only by approved procedure and with accountable personnel.

BIOS/UEFI passwords and access to settings: how to describe management

UEFI/BIOS passwords are often written as a single line in the tender and later found to be merely “cosmetic.” It is important to distinguish two mechanisms: the administrator password (protects entering settings and changing parameters) and the boot password (requested on power-on).

If the goal is to protect configuration and the boot chain, the admin password is the key. A power-on password is useful in some scenarios (e.g. devices in public areas) but does not substitute for restricting firmware settings.

Wording for a UEFI/BIOS password management section should be checkable at acceptance:

• Each PC supports an administrator password (Setup/Administrator Password) protecting access to UEFI/BIOS settings. Without it, parameter changes are impossible.
• A power-on/boot password is supported with the option to enable/disable it per the customer’s decision.
• Rights are separated: a non-admin user cannot change Secure Boot, TPM, boot order or enable booting from external media.
• The platform supports applying the customer’s policy for UEFI/BIOS settings (without mandating specific software).

Describe password change and storage organisationally, and require vendors to support it technically: “Passwords are set by an authorised customer representative; the supplier does not store or use passwords after handover. During factory preparation a temporary password is allowed but must be changed at commissioning.”

Also define how password reset is permitted. This reduces the risk of “universal” master codes. A normal variant: reset only via a service procedure in the organisation’s regulation, with proof of authority and a recorded service act.

At acceptance a few simple checks suffice: confirm that without the admin password parameters cannot be changed; enable a boot password and check it is requested at startup; attempt to change boot order without rights and log the failure.

Don’t forget lifecycle: at commissioning passwords are transferred to the responsible customer person by acceptance act, and at decommissioning a procedure for removal/reset is performed per internal rules.

How to compose the security section of a tender: a step-by-step template

A good security section starts not with technology names but with where and how the computers will be used. The same requirements look different for office PCs, classrooms, server racks and remote sites.

5-step template

First record context: user types, access level, whether remote administration exists, and whether standard OS images are required.

Then follow these steps:

1. Usage scenarios: office, classrooms, service desks, rack/DC, remote sites.

2. Mandatory functions: the practical minimum—usually TPM, Secure Boot and UEFI/BIOS settings protection.

3. Acceptance criteria: what is checked at delivery and who performs it. Wording must be testable: “enabled by default”, “settings access protected”, “status readable by standard OS tools”.

4. Documentation and support: short check instructions, password reset procedure via service, support requirements.

5. Coordination: circulate the draft with InfoSec and IT before publication. Remove contentious items like “only this chip” or “support all OS versions” unless critical.

To prevent Secure Boot, TPM and password sections becoming slogans, add an acceptance example: “In a 10% sample check the presence of TPM and enabled Secure Boot is confirmed, and BIOS/UEFI access requires an administrator password.”

Documents and acceptance: what proves the requirements are met

To avoid requirements remaining words on paper, tie them immediately to proofs. Acceptance and verification go faster when it is clear in advance which documents you expect and what to look for on a sample.

Documents to request from the supplier

Usually a standard set is sufficient. State that documents must match the supplied configuration and be provided in Russian or with translation.

Minimum set: product datasheet or form (model, serial number, completeness), delivery specification (including TPM presence and Secure Boot support as platform features), user guide or brief UEFI/BIOS checklist (how to check TPM/Secure Boot and set passwords), and a letter confirming conformity with the tender requirements and model.

If the supplier does integration and support, ask for a description of the typical security profile applied during batch preparation.

What to check on one or two samples

Acceptance is convenient to describe as a visual and functional check in UEFI/BIOS and in the OS without special equipment. The tender can specify a sampling rule, for example 1–2 devices per model.

Check what can be observed unambiguously:

• TPM: presence and state “enabled/ready for use” without requiring a specific chip vendor.
• Secure Boot: support, ability to enable it, and if preconfigured — an enabled state.
• Settings protection: UEFI/BIOS admin password and inability to change critical parameters without it.
• Boot access: prohibition or management of boot from external media (if your policy requires it).

How to describe uniform settings across a batch

Neutral wording: “All devices in the batch are supplied with a unified security profile agreed with the customer, with the ability to confirm parameters in a sample check.” This yields repeatable results without tying to specific models.

When a demonstration or pilot is appropriate

If this is the first purchase from a new supplier or requirements are critical (government body, bank, healthcare), add: “At the customer’s request the supplier provides a demo sample or pilot delivery to verify TPM, Secure Boot and UEFI/BIOS access management before the main batch is supplied.”

Typical mistakes in TPM, Secure Boot and password requirements

Problems are usually not in the number of requirements but in making them hard to implement or verify. The winner then is the one who “agrees verbally,” and acceptance turns into disputes.

First mistake — excessive specificity: “TPM only from this vendor, chip revision so-and-so.” This rarely increases protection but ties the procurement to a single option.

Second mistake — vague phrases: “increased security”, “protection against hacking”, “support for modern technologies.” They give no criteria: what is enabled, what may be disabled and how to check it.

Third mistake — requirements that cannot be accepted. If the verification method is not specified, acceptance becomes endless correspondence. For TPM, Secure Boot and passwords you can almost always describe checks via UEFI and standard OS tools.

A separate pain point is conflict with operation. Bans like “never allow any BIOS/UEFI changes” make updates, drive replacements and firmware recovery impossible. You need balance: who has access, how changes are recorded and how the standard profile is restored.

Assess each requirement with three questions:

• What exactly must be enabled or forbidden?
• How to verify this at acceptance?
• How will it work in operation?

Example procurement scenario and a set of tender phrases

A school or clinic buys a batch of PCs for general workstations: one room, multiple shifts, different staff. Typical risk: someone changes boot order, plugs in a USB, disables protection or leaves a shared admin password.

Below is a set of requirements that covers basic risks without tying to brands or models.

Set of phrases (5–7 requirements)

• PCs support TPM 2.0, available for enabling in UEFI/BIOS and recognised by the operating system.
• UEFI Secure Boot is supported with the ability to enable it. Delivery is performed with Secure Boot signature verification enabled where this does not contradict the chosen OS or corporate image.
• UEFI/BIOS administrator password can be set and controls changes to boot parameters. Without the admin password changing boot order and disabling Secure Boot is not possible.
• Ability to forbid booting from external media (USB, optical) or to control boot priority for external devices at the UEFI/BIOS level.
• UEFI/BIOS configuration reset is possible only with physical access to the device, without a remote bypass of passwords.
• The supplier does not add or change Secure Boot keys without the customer’s agreement.
• Delivery includes manufacturer documentation (or official guides) on enabling TPM, Secure Boot and managing UEFI/BIOS passwords.

How to describe acceptance and batch verification

To make requirements verifiable, describe acceptance so one unit and a sample are sufficient:

• Acceptance of one unit: on one PC the customer checks TPM 2.0 presence in the OS, Secure Boot state, an attempt to change boot order without a password (must be blocked) and confirmation that an admin password is set.
• Batch sampling: at least 10% of devices (but not fewer than 2 units) are checked with the same steps. If any device fails, an extended inspection is carried out under an agreed rule.

Handover of admin access and support

Define the procedure so the customer retains control but maintenance is not blocked:

• At commissioning the UEFI/BIOS admin password is set by a customer representative (in the supplier’s presence) or transferred to the customer via a regulated channel.
• The supplier does not retain admin passwords after delivery unless otherwise agreed by the customer’s regulation.

Quick checks and next steps before publishing the tender

Before publishing the tender run a short self-check:

• You described goals, not brands/models: “presence of TPM 2.0 and verifiable status” instead of “TPM from this vendor.”
• Each requirement is verifiable at acceptance: a UEFI screen, standard OS tools, inventory report or setup act.
• You separated “feature presence” and “configuration state.”
• Access management is described plainly: who changes settings, how login is protected, and what to do on reset.
• Contentious items are placed in an appendix: a table “requirement — verification — evidence.”

A minimal set for a typical office is TPM 2.0, enabled Secure Boot, a UEFI/BIOS admin password and restriction of external media booting. For higher requirements add firmware update control, change logging and stricter reset rules.

If you buy from a local manufacturer or integrator and need the batch delivered in a uniform state, agree in advance a “delivery security profile” (what is enabled, which parameters are recorded, how verification is performed). In practice this is convenient to discuss with a supplier who handles both hardware and deployment. For example, GSE.kz as a manufacturer and system integrator in Kazakhstan can often agree verifiable wording for acceptance and prepare a unified settings profile for L200 or M200 series.