This feature introduces the ability to perform on-demand measurements on the device, run the measurement (verify firmware integrity) of each component, and display the latest logs on the Cloud UI. It also enables a two-step attestation of measurements process by collecting OS data and introduces the concept of OS incidents, such as antivirus updates, BIOS mode switches, and BIOS version updates.
Running On-Demand Measurements from the Cloud
When you click the Run Measurement button in the TSFA Cloud UI, the following steps take place:
- Log Retrieval Visibility:
- The Cloud application shows the time and status of the most recent log retrieval, providing quick context on the last data collection. Once the measurements are successfully requested, the Report Status displays the corresponding value.
- Measurement Execution:
- The Cloud communicates with the Agent, requesting an on-demand measurement for the selected device.
- The Agent prompts the Embedded Controller (EC) to run the measurement process.
- Data Collection:
- The Agent gathers the results of the measurement.
- It collects the Trusted Platform Module (TPM) Platform Configuration Registers (PCRs).
- The Agent collects the OS-level information to detect any system changes.
- Cloud Processing:
- The Agent sends the measurements, TPM PCRs, OS data, and the latest BIOS log stored, to the cloud.
- The cloud backend compares the newly received data against known, trusted data.
- Suspicious Activity Detection:
- If discrepancies are found, the system generates an alert or incident for further investigation.
- Results Display:
- The Cloud UI displays the measurement summary in the device tray.
- If changes on the OS level are detected, they are shown in the Incident list or Device Lookup for easy review.

You can trigger measurements for multiple devices directly from the Cloud interface. Simply go to the Devices page, select the desired devices using the checkboxes, and click the Run Measurement button. If any of the selected devices are in a Pending state, are Unsupported, or already have a measurement request in progress, those devices will be automatically skipped.
Additional Improvements
- Clear Event Markers:
- Events are now clearly marked with their source, such as BIOS, OS, or EC, making it easier to identify the origin of changes.
- Quick Status Updates:
- The interface prominently shows the time and status of the last log retrieval, allowing you to assess the recency of your data.
- OS Monitoring
- The OS events will be generated not only during the data collection and processing for on-demand measurements, but also on a regular basis. The event will be generated in the Cloud as soon as a TSFA agent detects the changes in Windows security.
Limitations
- The measurements can be run only on devices with Active status. Check the Device Status before requesting the measurements.
- Make sure the selected devices are online before triggering measurements. If a device is offline when a measurement request is sent, the measurement will automatically be retrieved once the device comes back online.
Running On-Demand Measurements from TSFA Desktop
You can initiate On-demand measurements directly from the ThinkShield Firmware Assurance (TSFA) desktop application.
Click the Run Measurements button to initiate the process of requesting measurements from the embedded controller. The results will appear shortly as an entry in the main table.

When triggered directly from the desktop, on-demand measurements are not reported to TSFA Cloud. These results remain available locally.
BIOS vs EC Measurements
Both the EC and BIOS perform integrity and security health checks (measurements) for various system components.
BIOS: Automatically performs integrity checks during the boot process, ensuring that all critical firmware components are verified for security and authenticity without requiring user intervention. The result of the BIOS measurement is logged as Subcomponent Code Measurment event that can be found among the events on Device Lookup.
EC: Integrity measurements must be manually initiated by the user through the Cloud or Agent interface. The Run Measurements button enables users to request the EC to verify the integrity of three key components: the BIOS, EC firmware, and Flash Descriptor. The result is logged as On-demand Measurements and can be found among the events in Device Lookup. If any component is detected as corrupted, it will also appear under Incidents.
EC-Measured Components
- FD (Flash Descriptor): The Flash Descriptor defines access permissions and controls for various regions of the firmware. It serves as a critical security feature that prevents unauthorized modifications to specific areas of the BIOS.
- EC (Embedded Controller): The Embedded Controller firmware manages low-level hardware functions, such as keyboard input, thermal and power management, and sometimes fan control. It operates independently from the CPU and the operating system, remaining functional even in low-power or "off" states.
- BIOS (Basic Input/Output System): The BIOS serves as the system’s primary firmware interface between the hardware and the operating system. It initializes hardware components, provides configuration options, and transfers control to the operating system during the boot process.
BIOS-Measured Components
- BIOS (Basic Input/Output System)
- EC (Embedded Controller)
- FD (Flash Descriptor)
- Backup
- Ensures the integrity of the backup BIOS firmware used for recovery in case of corruption. This measure helps maintain system stability and facilitates the restoration of firmware integrity when needed.
- CSME (Converged Security and Management Engine)
- Verifies the integrity of the firmware responsible for platform security and remote management functions. CSME handles critical security operations, safeguarding the system against unauthorized access and firmware tampering.
- Desc (Descriptor Region)
- Ensures the integrity of access permissions and firmware settings within the descriptor region. This measure verifies that sensitive configuration data remains intact and protected from unauthorized modification.
- IBB (Initial Boot Block)
- Verifies the integrity of the first block of code executed during boot. The IBB ensures the security of the initial boot stages, preventing potential compromises before the operating system loads.
2-layer attestation for EC measurements
When the EC performs the measurement, the TSFA agent collects OS information from the device and generates an incident or event if any changes are detected. This process ensures firmware attestation at both the below-OS and above-OS levels. However, for BIOS-initiated measurements (Subcomponent Code
Measurements), OS information is not collected.
Incidents and their Source
Every incident or event displayed on the Incidents page includes the source of information that detected the change. These
incidents or events can originate from the BIOS, OS, or EC. BIOS events are generated
and logged as a result of the below-OS attestation that BIOS is conducting
with the help of EC during the boot.
On the above-OS level, TSFA agent can capture six distinct events:
- TPM PCR Change
- BIOS Mode Change
- BIOS Version Change
- Secure Boot Status Change
- Drive Encryption Status Change
- Disk Drive Firmware Version Change
With this release, OS events are introduced not only as a result of on-demand measurements but also as a part of routine security monitoring – the changes on the OS level will be reported to Cloud application whenever there is a change on the user's device.
For EC events, TSFA generates only one type of event: on-demand measurements. These events are recorded in the event list to support retrospective analysis, they can be
found on the Device Lookup or Incidents page.
The source of an event can be viewed by clicking on the Incident tray.