research
Measuring endpoint encryption coverage from management console data
A method for reconciling console encryption reports with the real endpoint population and verifying a sample on the device before quoting a coverage figure.
Use this benchmark to size repeatable IT work, set the review cadence, and decide what stays with the technical owner before assigning the workflow to an IT virtual assistant.
Research playbook
On this pageJump to section
Key stats
Key takeaways
Encryption coverage is often reported as a single percentage from a management console, but the number depends on which devices are counted. A console can show ninety-five percent while the missing five percent includes the laptops most likely to leave the building. This study defines the covered population, reconciles the console export, and verifies a sample on the endpoint. The result is a coverage figure an IT manager can defend.
Question and scope
This study asks what share of managed endpoints have encryption enabled and protecting the system volume, which device groups account for the gap, and whether the console figure matches the endpoint state. The unit is one managed device, and the population is every device enrolled during a declared week. The result describes that fleet and that period, not the encryption policy of the whole company. Freeze the device scope and the collection date before exporting data.
Include laptops, desktops, and virtual machines that store company data on a local disk. Exclude servers and mobile phones unless the same management console reports them and the same policy applies. Record the operating system and the device owner group. A coverage figure that mixes device types can hide a gap in the group that matters most. Record the device type and the owner group because a fleet average can hide a small high-risk set.
Define the covered population
Count a device as covered only when encryption is enabled, the key protector is present, and the system volume is fully encrypted. A console status of compliant is not enough on its own, because the status can reflect an old check. Record the definition in the report so the percentage cannot be read as something broader. The definition should be strict enough to survive an auditor's question. The key protector must be escrowed before the device is considered covered.
Decide how to treat a device that is enrolled but has not reported for more than thirty days. Exclude it from the numerator and report it as unreported rather than compliant. The same rule applies to a device that was wiped and re-enrolled under a new identifier. Hiding either group inflates coverage without improving security. A device that is pending retirement should not be counted as covered before it leaves.
Build the console export
Export the device identifier, the hostname, the operating system, the last check-in, the encryption status, the key protector type, and the policy applied. Add the device group and the assigned user where the console stores them. Save the raw export with the collection date. A screenshot of a dashboard is not a dataset and cannot be reconciled.
Check whether the console reports status per volume or per device. If it reports per volume, aggregate carefully so a device is not counted twice. Note the difference between a policy that requires encryption and a device that has completed it. A policy assignment is an intention, while the status is evidence. Record the console's definition of compliant beside the fields used in the export.
Reconcile the denominator
Compare the console device count with the asset register and the identity provider's managed device list. Investigate every device that appears in one source but not the others. Record devices that are pending retirement, in repair, or assigned to a departed user. The denominator is the part of the study most likely to be wrong.
Remove duplicates caused by renamed devices, reimages, or multiple agents. Keep a mapping table so the same physical machine is not counted twice. Report the number of devices excluded and the reason for each group. A coverage figure without a reconciled denominator is only a console reading. Keep the mapping table with the report so a later reviewer can see which records were merged.
Classify the exceptions
Group the uncovered devices into policy not applied, encryption in progress, key protector missing, hardware without a supported encryption module, and unreported. Give each group an owner and a next action. A device that is mid-encryption is different from one that has never received the policy. The classification tells the owner whether to wait, repair, or replace.
Check whether any group is exempt by policy, such as a lab machine that never stores company data. Record the exemption and its approval. An exemption without a written reason becomes an invisible gap. Keep the exempt count separate from the covered count so the headline remains honest. An exemption that cannot be produced on request should be treated as missing.
Verify a sample on the endpoint
Select a random sample of at least twenty devices across the covered and uncovered groups. Check the encryption status directly in the operating system settings or the management command. Confirm the system volume and any secondary data volume. Compare the result with the console record.
For covered devices, confirm that the recovery key is escrowed where the policy requires it. A device can be encrypted and still be unrecoverable if the key is missing. For uncovered devices, record the reason shown on the device. The sample tests the console data and the recovery process at the same time. Record the recovery key escrow status for each sampled device.
Estimate the gap
Report the covered share with the confidence range implied by the sample and the reconciled denominator. Show the raw counts beside the percentage so the reader can see the size of the fleet. Break the result down by device group and operating system. A single fleet-wide number can hide a small group with a large risk.
Describe the exposure in terms of devices that could be lost or stolen with readable data. Avoid inventing a breach probability or a fine amount. Note the existing controls such as remote wipe, device lock, and conditional access. The estimate should support a decision about the uncovered group rather than produce a general alarm. A device that is locked but unencrypted still carries readable data if the drive is removed.
Report to the owner
Lead with the reconciled device count, the covered share, and the largest uncovered group. Show one example of a console record that did not match the device. Explain the denominator and the exclusions in a short note. Keep the technical detail in an appendix for the endpoint owner. Keep the uncovered count on the first page rather than in an appendix.
Ask for specific decisions such as replacing unsupported hardware, correcting the policy assignment, or escrowing missing recovery keys. Name the owner and the review date. If the decision is to accept an exempt group, record the reason and the compensating control. A documented exception is part of a defensible coverage figure.
Limits and next use
The study measures the devices the console can see and the state reported at collection time. It does not detect an unmanaged device that stores company data outside the fleet. It also cannot prove that encryption protects against every threat, because the key management and the user's behaviour matter. State those limits so the figure is not oversold.
Repeat the measurement after a policy change or a hardware refresh and compare the same groups. If coverage rises but the unreported count also rises, the fleet may be growing faster than the management agent. That is a different problem from a failed policy. Record the collection dates so the two readings are not confused.
Repeat after remediation
Set a follow-up date for the largest uncovered group and check the same fields again. Record which devices moved into coverage and which did not. Investigate a device that remains uncovered after a remediation attempt rather than marking it complete. The follow-up is where a report becomes a control. Record the remediation action and the date it was attempted.
Keep the query and the reconciliation steps with the report so the next reviewer can repeat them. Compare the trend over three measurements before declaring success. A one-time improvement can come from a hardware refresh rather than a process change. The measurement is useful when it shows which action moved the number. Use the same collection window each time so the comparison is fair.
Sources and next step
Use the NIST Cybersecurity Framework 2.0 and the CISA Cross-Sector Cybersecurity Performance Goals as primary references for the recovery, software inventory, service desk, DNS, and endpoint protection controls discussed here. The GAO data reliability guidance supports the sampling and verification approach used in these methods. Apply your own policies, contracts, and system documentation when adapting the method.
Compare this study with the endpoint encryption coverage study and the public DNS change authority audit before combining them into one review cycle. If the measurement work is recurring and your technical owner can define the scope, review the service areas and contact ITVirtualAssistant to discuss a limited pilot.
Benchmark brief
What this research page must produce
A practical estimate for volume, review time, escalation rate, and assistant capacity.
A clear split between routine support, preparation work, and technical ownership.
What the measuring endpoint encryption coverage from management console data data shows
Treat this as a planning benchmark, not a universal number. Compare the benchmark against your ticket volume, SaaS stack, documentation backlog, and support risk before assigning recurring work.
The useful output is a decision about capacity, not a static statistic. If the workflow is high volume and low judgment, an IT virtual assistant can absorb coordination and upkeep. If the workflow is low volume but high risk, keep it with the technical owner and use the assistant only for preparation, reminders, and documentation.
Workflow
Recommended operating workflow
Collect a baseline
Pull the last 30 to 90 days of examples related to measuring endpoint encryption coverage from management console data, including completed work and unresolved exceptions.
Classify the work
Tag each item by routine admin, manager approval, technical decision, security risk, or vendor dependency.
Set the operating number
Use the median weekly volume and review time to decide how many assistant hours the workflow deserves.
Refresh the benchmark
Recheck the numbers quarterly so tool growth, new systems, and security requirements do not silently change the scope.
Decision rules
| Metric | Use it to decide | Manager action |
|---|---|---|
| Weekly volume | Whether the workflow is worth assigning as recurring assistant work. | Approve a weekly capacity target and backlog threshold. |
| Access sensitivity | Whether the assistant can work directly or only prepare review notes. | Set least-privilege permissions and removal dates. |
| Escalation rate | Whether the workflow is stable enough to delegate. | Rewrite the SOP when exceptions exceed the agreed threshold. |
Consolidated statistics
| Statistic | Figure | Source |
|---|---|---|
| Sample floor | 20 devices | Study protocol |
| Exception groups | 5 | Study protocol |
| Unreported threshold | 30 days | Study protocol |
Sources
- NIST SP 800-111, Guide to Storage Encryption Technologies for End User DevicesStorage encryption technologies, key management, and recovery considerations.
- NIST SP 800-53 Rev. 5Protection of information at rest and cryptographic key management controls.
- CISA Cross-Sector Cybersecurity Performance GoalsData protection and asset management goals for small organizations.
- NIST Cybersecurity Framework 2.0Data security and asset management outcomes for endpoint fleets.
- GAO Assessing Data ReliabilityDenominator reconciliation and sampling checks for coverage estimates.
Measurement checklist
| Field | What to capture | Owner |
|---|---|---|
| Volume | Weekly request count, backlog age, and repeat issue patterns | Assistant prepares, manager reviews |
| Risk | Access level, customer impact, security sensitivity, and approval needs | Technical owner |
| Cadence | Daily, weekly, monthly, or quarterly review rhythm | Manager |
| Evidence | Sample tickets, logs, screenshots, and before-after examples | Assistant collects, owner validates |
| Escalation | Triggers, approval path, response time, and stop-work rules | Technical owner |
How to read the result
A good research page should leave the manager with a working number and a clear boundary: what the assistant can do every week, what the assistant can prepare for review, and what must never move without the accountable technical owner.
Source and refresh note
This planning page is dated for 2026 and should be refreshed quarterly as tool stacks, ticket patterns, and security expectations change.
How should teams use this benchmark?
Use it to define task volume, access limits, review cadence, and escalation rules before assigning work.
Get free benchmark review