Boot & Security Inventory
For every managed machine, Athena collects its firmware and platform-security posture: whether Secure Boot is on, whether a TPM is present and in what state, the BIOS/UEFI vendor and version, and whether the machine is waiting on a restart. This gives you a fleet-wide readiness picture — for example, which endpoints are ready for a modern OS upgrade or meet a hardware-security baseline — without touching each device.
This is read-only discovery. Athena reports the firmware and TPM state each machine already has; it does not enable Secure Boot, provision or clear a TPM, or flash firmware. Changing those settings remains a task for firmware/OS tooling on the endpoint.
What's collected#
The Boot & Security record captures the following for each machine:
| Field | Meaning |
|---|---|
| Secure Boot (UEFI) | Whether UEFI Secure Boot is currently enabled on the machine. |
| Setup Mode | The firmware mode the machine booted in — UEFI or legacy BIOS. Secure Boot is a UEFI feature, so a legacy-BIOS machine reports Secure Boot as disabled. |
| BIOS Manufacturer | Firmware vendor (for example, the system or board maker). |
| BIOS Version | Firmware version string reported by the machine. |
| BIOS Release Date | Firmware release date — useful for spotting machines on years-old firmware. |
| TPM Present | Whether a Trusted Platform Module chip is detected. |
| TPM Version | The TPM specification level, normalized to 2.0 or 1.2 when it can be determined. |
| TPM Enabled | Whether the TPM is enabled. |
| TPM Activated | Whether the TPM is activated (ready for use). |
| Restart Pending | Whether the machine is waiting on a reboot to finish applying updates or file/servicing changes. |
Disk encryption is not part of this record. Athena's inventory does not report BitLocker or other disk-encryption state. If you need to verify encryption status, the practical approach is a compliance rule or a custom scan that queries it on the endpoint and surfaces the answer through the scan results — which you can then use in collections, tagging, and reports just like any other collected field.
Platform coverage#
Boot & Security is collected on both Windows and Linux endpoints. The same fields are reported on each platform, using each operating system's own native facilities to read firmware, Secure Boot, and TPM state, so a fleet with a mix of both answers the same questions consistently.
| Aspect | Windows | Linux |
|---|---|---|
| Secure Boot / Setup Mode | Read from the platform's Secure Boot state; reported as UEFI or legacy BIOS. | Read from the platform's Secure Boot state and firmware type. |
| TPM present / version / enabled | Full detail, including activated state. | Detected via the standard TPM device; on Linux an enabled TPM is treated as activated. |
| BIOS/UEFI vendor, version, date | Reported. | Reported where the system exposes it. |
| Restart pending | Reflects Windows servicing / update / pending file-rename state. | Reflects the distribution's reboot-required signal. |
Values that a machine genuinely can't report (for example, a TPM version that can't be
determined) are shown as N/A rather than guessed.
Where to see it#
Open a machine from the Agents list, then in the agent detail view's left-hand navigation choose Boot & Security. The section lays out every field above as a simple grid so you can read a single machine's firmware and TPM posture at a glance.
Like the rest of inventory, the values reflect the machine's last successful collection on its regular reporting cadence rather than a live query at open time. For the wider inventory surface and refresh behaviour, see Inventory.
Filtering, tagging & collections#
Boot & Security posture is more than a per-machine readout — four of its values are first-class fields you can filter on. They appear under the Security category in the field picker wherever Athena builds a machine filter: dynamic collections, automatic tagging rules, and the report builder.
| Field | Type | Example values |
|---|---|---|
TPMPresent | Boolean | True, False |
TPMVersion | Text | 2.0, 1.2 |
TPMEnabled | Boolean | True, False |
SecureBoot | Text | Enabled, Disabled, Not Supported |
Typical uses:
- A dynamic collection of machines missing a TPM (
TPMPresent = False) or on TPM 1.2, to scope a hardware-refresh or upgrade-readiness campaign. - An automatic tag such as
secureboot-offfor machines whereSecureBootis not enabled, so they surface in dashboards and targeting. - A collection of machines that have Secure Boot on and a TPM 2.0 enabled, as the target group for a policy or deployment that requires them.
Because these are ordinary filter fields, they combine freely with any other inventory criteria (OS, model, domain, and so on) using the same collection filter builder.
Reporting fleet-wide#
To produce a shareable, exportable view across the whole fleet, use the report builder with the Agents data source. Its column picker includes the same security fields, so you can build, for example, a "Secure Boot & TPM readiness" report:
| Column | Shows |
|---|---|
SecureBoot | Whether Secure Boot is enabled on each machine. |
TPMPresent | Whether a TPM is detected. |
TPMEnabled | Whether the TPM is enabled. |
TPMVersion | The detected TPM specification level. |
Add machine-identifying columns (such as hostname and model), apply any filters you like, and run or save the report. Reports can be exported and saved as reusable definitions — see Reports for formats, saved definitions, and scheduling.
Reading it over the API#
Boot & Security is part of an agent's full inventory. Fetch the complete inventory document
and read the bootSecurity section:
# Fetch the full inventory for one agent, then inspect boot & security posture
$headers = @{ Authorization = "Bearer $token" }
$inv = Invoke-RestMethod `
-Uri "https://athena.example.com:8443/api/agents/$agentId/inventory" `
-Headers $headers `
-SkipCertificateCheck
$inv.data.bootSecurity.secureBootEnabled
$inv.data.bootSecurity.tpmPresent
$inv.data.bootSecurity.tpmVersion
$inv.data.bootSecurity.restartPending
Reading inventory requires the Helpdesk role or higher. The
bootSecurity object is null when a machine has not yet reported this
data. For the full inventory surface and the PowerShell module used to script against the server,
see Inventory and the
PowerShell Module reference.