Health Score
The health score provides a single metric (0-100) that summarizes each agent's overall security posture. It combines vulnerability exposure, compliance status, update currency, and network exposure into a weighted score that helps you prioritize remediation efforts.
How the Score Is Calculated
The overall health score is a weighted average of four independent category scores:
| Category | Default Weight | What It Measures |
|---|---|---|
| Vulnerabilities | 50% | Known CVEs in installed software and OS |
| Compliance | 25% | Adherence to assigned compliance frameworks |
| Pending Updates | 15% | Outstanding system and application updates |
| Network Exposure | 10% | Open ports, firewall state, and attack surface |
Each category produces its own score from 0 to 100, and the overall score is the weighted combination:
Overall = (Vulnerability x 0.50) + (Compliance x 0.25) + (Updates x 0.15) + (Network x 0.10)
Weights are configurable per-tenant in Settings > Health Scoring.
Score Ranges
| Score | Status | Meaning |
|---|---|---|
| 80-100 | Healthy | System is secure and compliant |
| 60-79 | Needs Attention | Action required but not critical |
| 0-59 | Critical | Immediate attention required |
Category Scoring Details
Vulnerability Score
Starts at 100 and deducts points based on open vulnerabilities:
| Factor | Penalty |
|---|---|
| CISA KEV (Known Exploited Vulnerability) | -15 per vulnerability |
| KEV past its remediation due date | -25 additional per overdue KEV |
| Critical severity (CVSS 9.0-10.0) | -10 per vulnerability |
| High severity (CVSS 7.0-8.9) | -5 per vulnerability |
| Medium severity (CVSS 4.0-6.9) | -2 per vulnerability |
| Low severity (CVSS 0.1-3.9) | -0.5 per vulnerability |
| Fix available but not applied | -1 per vulnerability |
KEV vulnerabilities and critical CVEs have the largest impact because they represent the highest real-world risk.
Compliance Score
Weighted average of all compliance framework scores assigned to the agent through its tags. If no frameworks are assigned, the score defaults to 100.
Frameworks with critical failures are weighted more heavily. A framework reporting multiple critical failures counts more in the average than one with only minor non-compliance.
Update Score
Starts at 100 and deducts points for pending updates and stale check-in data:
| Factor | Penalty |
|---|---|
| Pending Windows/system update | -4 per update |
| Pending application update | -2 per update |
| Software needing updates | -1 per package |
| No update check in 7+ days | -5 |
| No update check in 14+ days | -10 additional |
| No update check in 30+ days | -20 additional |
Agents that have not checked for updates recently receive escalating penalties.
Network Exposure Score
Starts at 100 and deducts points based on exposed ports and firewall state.
If the firewall is disabled, the network score is automatically 0. This reflects the critical importance of having a host firewall active.
When the firewall is enabled, points are deducted per exposed port based on risk level:
| Port Risk Level | Penalty |
|---|---|
| Critical (e.g., Telnet, FTP) | -25 per port |
| High (e.g., RDP, SMB internet-exposed) | -15 per port |
| Medium | -5 per port |
Port risk is context-aware. A port that is only accessible on localhost or blocked by the firewall has no impact. The same port exposed to the internet is penalized based on the service type.
Viewing Health Scores
Agent Detail Page
Navigate to any agent and select the Health tab to see:
- Overall score gauge: Circular gauge showing the 0-100 score with status label
- Category cards: Four cards for Vulnerabilities, Compliance, Updates, and Network, each showing their individual score and key metrics
- 30-day trend chart: Area chart showing score history with toggleable series for overall and each category
- Fix These First: A prioritized list of the most impactful remediation actions, ranked by severity. Items link directly to the relevant tab for that agent.
- History panel: Timeline of score-impacting events over the last 30 days (e.g., "New critical vulnerability detected", "3 pending updates installed")
Fleet Summary
The agent list shows each agent's health score, allowing you to sort and filter by health status. The endpoints table includes a health score column to quickly identify agents that need attention.
Trend Analysis
The system tracks daily health scores for 30 days and calculates a trend:
| Trend | Condition |
|---|---|
| Improving | Score increased by more than 0.5 points over the period |
| Stable | Score changed by less than 0.5 points |
| Declining | Score decreased by more than 0.5 points |
| New | Agent has less than 7 days of history |
Trends require at least 7 days of data to avoid false signals during the initial assessment period.
Configuring Weights
Navigate to Settings > Health Scoring to adjust how much each category contributes to the overall score.
- Weight sliders: Adjust the weight of each category. Weights automatically balance to total 100%.
- High-risk port configuration: Define which ports are considered critical, high, or medium risk for the network exposure calculation.
For example, if your organization prioritizes compliance over vulnerability patching, you could increase the Compliance weight and decrease the Vulnerability weight. The default weights reflect a security-first posture where known vulnerabilities carry the most impact.
Prioritized Actions
The "Fix These First" section on the Health tab generates up to 7 actions ranked by impact:
- CISA KEV vulnerabilities (sorted by remediation due date)
- Critical CVEs without KEV designation
- Critical and high-severity compliance failures
- High-risk network port exposures
Each action includes a severity indicator and links directly to the relevant section of the agent detail page where you can take corrective action.
Servicing Health
Servicing Health, on the endpoint Health tab, runs pre-flight checks that look at the system state Windows cumulative updates depend on. When one of these checks fails, the next cumulative update will install, reboot, then roll back at 98% with errors like 0x800f0922 and revert to the prior state. The Servicing Health section surfaces the failing check up front so you can fix the underlying cause before triggering an install, instead of troubleshooting the failure afterward.
This section appears on Windows endpoints only. The status badge in the section header summarizes the endpoint's overall readiness:
| Badge | Meaning |
|---|---|
| Ready for updates | All checks passed. The endpoint is in a state where cumulative updates can install successfully. |
| Action recommended | One or more checks returned a warning. The next update may still install, but the warned-on subsystem (for example, free space approaching its threshold) is worth addressing. |
| Update install blocked | One or more checks returned a critical finding. Cumulative updates that try to install in this state are expected to fail. The fix is shown inline along with the relevant Microsoft KB article. |
The badge is a forecast of whether the next cumulative update will succeed. It is separate from whether the agent will attempt the install at all. The agent holds installs on its own only for a small set of checks it can measure locally, such as low free space on C:. When the agent is holding installs, the Servicing Health section says so directly under its header. A red badge without that line means scheduled updates will still be attempted and are expected to fail until the finding is resolved.
When everything is healthy, the section displays a single line confirming all checks passed and the timestamp of the most recent measurement. When a check fails, only the failing checks are listed, each with a plain-language summary, the recommended fix, and a link to the Microsoft KB article that documents the supported repair procedure.
Checks performed
| Check | What it looks at | Why it matters |
|---|---|---|
| WinRE Configuration Consistency | The reagentc /info output, C:\Windows\System32\Recovery\ReAgent.xml, and the WinRE entry in the Boot Configuration Data store. The check passes when WinRE is disabled, or when WinRE is enabled and the BCD identifier in ReAgent.xml matches what reagentc reports. | Cumulative updates refresh winre.wim when WinRE is enabled. When ReAgent.xml references a partition or BCD entry that no longer exists (a common state on long-lived imaged systems), the install reaches the post-reboot commit phase and reverts. The Microsoft-supported reset script in KB5034957 is the standard repair. |
| EFI System Partition Free Space | The total and free bytes on the GPT EFI System Partition (mounted briefly via mountvol). | Post-April 2026 cumulative updates ship larger boot files than the legacy 100 MB ESPs common on older Windows 10/11 systems can absorb. The check warns at <100 MB free and flags critical at <50 MB free. Resize procedure is documented in KB5028997. |
| Recovery Partition Size | The total size of the partition that holds winre.wim, identified by parsing the WinRE location reported by reagentc /info and looking up the partition with Get-Partition. | winre.wim has grown across recent feature updates; recovery partitions sized to the legacy 500 MB no longer fit the current image. The check flags a partition that cannot hold the current recovery image: below 520 MB on Windows 11 24H2 and later, below 750 MB on earlier builds. Larger partitions with limited headroom are reported as informational. Only the WinRE update is affected, so this check never blocks other updates. The resize procedure is documented in KB5035679 (a Microsoft-supported script) and KB5028997 (manual steps). |
| CBS Pending Operations | HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PendingRequired and RebootPending registry keys, plus C:\Windows\WinSxS\pending.xml. | Pending Component-Based Servicing operations from a previous failed update or feature change block subsequent cumulative updates from installing. The check warns when any indicator is present and recommends dism /online /cleanup-image /restorehealth followed by a reboot. |
| C: Free Space | The free bytes on the C: drive (queried directly via Win32 GetDiskFreeSpaceExW). | Cumulative updates download and stage content under C:\Windows\SoftwareDistribution and C:\$WinPE_Boot before installing. Recent CUs need 8-10 GB of headroom at peak. The check warns at <20 GB free and flags critical at <10 GB free. |
| CheckSUR Errors | The last 256 KB of C:\Windows\Logs\CBS\CheckSUR.log, counting (f) lines that are not followed by a (fix) line on the next non-blank row. | Unrepaired entries in the CheckSUR log strongly correlate with cumulative update failures. The check warns when any unrepaired errors are present and recommends dism /online /cleanup-image /restorehealth and sfc /scannow. |
| Servicing-Critical Services | The startup type of the Windows services that cumulative updates depend on: App Readiness, AppX Deployment Service, Client License Service, State Repository Service, Windows Modules Installer, Windows Update, and Update Orchestrator Service. | A disabled servicing service makes the update fail during the post-reboot commit phase, commonly with 0x800f0922. The check reports a critical finding when App Readiness or Windows Modules Installer is disabled, since either one stops every cumulative update from installing, and a warning for the other services. |
| Component Store Corruption | The last 256 KB of C:\Windows\Logs\CBS\CBS.log for component store corruption markers. | A missing or damaged component store causes cumulative updates to fail to install. The check reports a critical finding when a specific corruption marker is present (for example ERROR_SXS_ASSEMBLY_MISSING, ERROR_SXS_COMPONENT_STORE_CORRUPT, or CBS_E_STORE_CORRUPTION), a warning when only the missing-source marker (CBS_E_SOURCE_MISSING) is present, and an informational note when only the generic 0x80070490 code appears without any corruption marker. It recommends dism /online /cleanup-image /restorehealth. |
| Component Store Install Failure | Raised by TridentStack Control when a system update install on the endpoint fails with a component store error code, rather than by a probe on the endpoint. | Reported as critical for the specific corruption codes (0x80073701, 0x80073712, 0x800F0831, 0x800F081F) and as a warning for the generic 0x80070490 code. It clears automatically after the next fully successful system update install. |
| Out-of-Support .NET Runtime Installed | The installed .NET runtime lines and their support dates. | An out-of-support runtime no longer receives security updates. Move the applications that depend on it to a supported .NET release, then remove the runtime. |
| .NET SDK Installed Outside Update Management | .NET SDK versions installed on the endpoint. | System updates do not service SDK releases. Update the SDK through the package that installed it, such as winget, Visual Studio, or the installer. |
Frequency
Probes run shortly after the agent connects to the server (on agent startup, restart, or reconnect). Findings are stored as the latest known state, one row per check per endpoint, so the section reflects the most recent measurement rather than a history. To re-run probes manually, restart the TridentStack Control agent service on the endpoint.
What to do when a check fails
- Read the Fix line on the failing check for a one-sentence summary of the supported repair.
- Click the linked Microsoft KB article for the full procedure.
- After running the repair on the endpoint, the next probe submission will clear the finding (or, if the issue persists, re-flag it with details that help narrow down the cause).
Dismissing a finding
You can dismiss a specific Servicing Health finding for a single endpoint. A dismissed finding stops counting toward that endpoint's Update Health and is shown as "Exempted".
The finding details, the check, the plain-language summary, the recommended fix, and the Microsoft article link, are selectable text with a "Copy details" action, so you can send them to whoever owns the endpoint.
Dismissing hides the finding from your dashboards; it does not change the endpoint itself. If the agent is holding installs because of that finding, it keeps holding them until the underlying issue is resolved, and the Servicing Health section continues to say so. You can restore a dismissed finding at any time.
The same details and Dismiss action are also reachable from the Update Health status on the Endpoints list. Clicking a flagged Update Health status opens the details.