Build a dated register that follows sensitive data through the apps, devices, cloud services, storage locations, and network connections that handle it. For each part of that path, record what kind of encryption you checked, the evidence and date, who controls the keys or recovery, and any exceptions. Mark unverified coverage as unknown—a missing report is not proof that data is encrypted.
What an encryption inventory needs to cover
“Encrypted” is not a single status. A laptop may encrypt its drive while an app sends information to a service over TLS; the service may encrypt stored files with provider-managed keys, while a separate end-to-end encryption feature is optional. Those protections answer different questions. No one device setting or vendor dashboard necessarily covers the entire route your data takes.
As an Amazon Associate I earn from qualifying purchases.
| Layer or question | What to establish | What it does not establish by itself |
|---|---|---|
| Device or storage encryption at rest | Whether the device drive, removable storage, database, or other storage location is encrypted, and whether that protection is enabled on the specific asset. | That every app, backup, cloud copy, or recipient’s device is covered. |
| Cloud encryption at rest | Whether the specific service and data category are encrypted while stored, and whether keys are provider-managed or customer-controlled. | That only you can decrypt the data, or that all service data types use the same settings. |
| Encryption in transit | Whether connections such as sign-in, synchronization, API calls, and file transfers use an appropriate protected transport, and which endpoints are included. | That data is encrypted after it reaches a server, or that the provider cannot access it. |
| Application-level or end-to-end encryption | Whether an app encrypts data before storage or transmission, whether the feature is enabled, and who can decrypt or recover it. | That all app functions, metadata, attachments, backups, or account recovery flows receive the same protection. |
| Key and recovery control | Who can create, access, rotate, revoke, escrow, or recover keys, and what happens if a key or account is lost. | That encryption is enabled or correctly applied to every data location. |
NIST’s key-management guidance treats keys, their protection, the functions they support, and inventory as related management concerns. Its organizational guidance also addresses documentation and inventory management; the register below is a practical working format, not a spreadsheet format mandated by NIST. See NIST SP 800-57 Part 1 Rev. 5 and Part 2 Rev. 1.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How to build the register
1. Choose a scope and an owner
Start with a person, team, or business unit. List the data it handles—for example, customer records, payment or health information, employee files, source code, credentials, backups, and business documents. Then identify the apps, devices, cloud services, shared storage, and externally reachable services that create, process, store, back up, or transmit that data. Assign an owner to each record; for a personal inventory, that can be you.
#1 Best Overall
- Hardware encrypted drive
- Simple to use pin access. RPM-5400
- Administrator password feature
- Bus powered
- Utilizes Military Grade FIPS PUB 197 Validated Encryption Algorithm
Follow the data path rather than making a list of products alone. A customer file might move from a work laptop to a browser app, into a cloud service, and then into a backup or export. Record each relevant stop and connection. NIST’s cloud key-management analysis explains why key management can become more complex when cloud consumers and providers have different ownership and control over infrastructure; it is architecture context, not a current configuration guide for an individual product. See NIST IR 7956.
2. Record the same fields for each asset and data path
A spreadsheet or asset-management system can use these fields. Add a separate row when one service handles materially different data, settings, or key arrangements.
- Identity and responsibility: record ID, personal or business owner, service or device owner, and remediation owner.
- Data and impact: data type, sensitivity, and likely impact if exposed.
- Where it goes: app or service, device and operating system/version, storage location, backup destination, and relevant network connection.
- Protection being checked: at rest, in transit, app-level/end-to-end, or key and recovery handling; name the feature or protocol and note whether it is enabled, required, or optional.
- Evidence: verification method, evidence location, date checked, and whether the result was observed in a setting or report, inferred, or taken from vendor documentation.
- Key and recovery details: custodian, roles with access, recovery path, and who is responsible for rotation or expiration where relevant.
- Disposition: status, exception and rationale, remediation owner, and due date.
Protect the inventory itself. It can reveal sensitive details about systems, access roles, recovery routes, and key administration. NIST SP 800-57 Part 1 Rev. 5 discusses protecting keying material and associated metadata.
Free tools Windows power users keep installed
One-click scans. No signup required.
3. Use explicit status labels
Do not collapse unsupported, missing, and unverified results into a simple yes/no answer. Google’s device policy reference, for example, distinguishes ENCRYPTED, UNENCRYPTED, ENCRYPTION_UNSUPPORTED, and ENCRYPTION_UNSPECIFIED. Those labels illustrate why a register needs a meaningful unknown state: Google Cloud Asset reference.
Rank #2
- Utilizes Military Grade FIPS PUB 197 Validated Encryption Algorithm
- Super fast USB 3.0 Connection - Data transfer speeds up to 10X faster than USB 2.0
- Software Free Design - With no admin rights needed
- Sealed from Physical Attacks by Tough Epoxy Coating
- Brute Force Self Destruct Feature
| Status | Use it when |
|---|---|
| Confirmed encrypted | Current, asset-specific evidence establishes the relevant encryption layer and configuration. |
| Confirmed not encrypted | Evidence establishes that the relevant layer is absent or disabled. |
| Unsupported | The device, service, or configuration does not support the protection being assessed. |
| Unknown / not reported | The setting was not checked, a report is missing or stale, or the available evidence does not establish the answer. |
| Not applicable | The particular encryption check does not apply to that record; note why rather than leaving the field blank. |
How to check computers and mobile devices
Windows
On a Windows device, check Settings → Privacy & security → Device encryption if the page is available. Microsoft describes Device Encryption as enabling BitLocker automatically for the operating-system drive and fixed drives, but whether it activates automatically depends on device and account conditions; using a local account does not automatically enable it. A missing setting is not confirmation that the drive is encrypted. Microsoft directs users to check System Information for Device Encryption Support and prerequisites such as TPM and Windows Recovery Environment support. The same documentation says BitLocker Drive Encryption is available on Pro, Enterprise, and Education editions, while Device Encryption is available on a wider range that includes some Home devices. Check the specific computer and edition rather than generalizing across Windows: Microsoft: Device Encryption in Windows.
Apple devices
Use platform-aware records rather than one blanket “Apple encryption” entry. Apple describes iPhone and iPad as using file-based Data Protection, Intel Macs as using FileVault volume encryption, and Apple silicon Macs as using a hybrid model with stated caveats. Verify the actual device and operating-system configuration: Apple’s Encryption and Data Protection overview. In organizational deployments, Apple documents managing FileVault through device management and escrowing recovery keys: Manage FileVault with device management.
Managed fleets
For supported, enrolled Windows and macOS devices, Microsoft Intune’s encryption status report provides status details, CSV export, and recovery-key management routes. Its documented report scope lists macOS 10.13 or later and Windows version 1607 or later; this does not mean every compatible device is enrolled or reporting. Use the report as evidence for the devices it covers, not as an inventory of personal endpoints, other platforms, or SaaS apps. The page was last updated September 28, 2026: Intune encryption status report. Intune also lists BitLocker and FileVault capabilities and device compliance policies in its security overview.
For Android and Linux, verify the relevant operating-system, device-manufacturer, and management-console evidence for the actual device. Until that evidence establishes the state, record it as unknown rather than assuming coverage.
Rank #3
- Slim durable design to help take your important files with you
- Vast capacities up to 6TB[1] to store your photos, videos, music, important documents and more
- Back up smarter with included device management software[2] with defense against ransomware
- Help secure your important files with password protection and hardware encryption
- 3-year limited warranty
How to check apps and network connections
For every app, trace what it receives, stores locally, synchronizes, exports, backs up, and sends to other services. Check these questions separately:
- Are local files or databases encrypted?
- How is content and backup data protected in cloud storage?
- Are sign-in, API, sync, and file-transfer connections encrypted in transit?
- Is end-to-end encryption available, and is it enabled for this account and data type?
- Who controls keys, recovery, administrative access, and provider access?
Transport security is not evidence of storage or end-to-end protection. Apple’s developer security overview describes App Transport Security policies for secure network communication using TLS 1.2, forward secrecy, and strong cryptography separately from Keychain, app sandboxing, and certificate trust. Those are distinct security functions: Apple Security Overview.
Include externally exposed endpoints and certificates in the transport portion of the inventory. NIST SP 800-57 Rev. 5 discusses inventory management for keys and certificates; NIST’s publication announcement is at NIST’s SP 800-57 Part 1 Rev. 5 announcement. A service-specific requirement must stay service-specific: AWS says clients accessing AWS Organizations APIs must support TLS 1.2 and recommends TLS 1.3. That statement does not establish the requirements for every AWS service: AWS Organizations infrastructure security.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteHow to check cloud services and key responsibility
For each IaaS, PaaS, or SaaS service, record the provider, account, data location, data category, and the service-specific evidence for encryption at rest and in transit. Identify the available key-management options and who can administer or recover keys. Distinguish provider-managed default encryption from customer-controlled keys and from application-level end-to-end encryption: these are different arrangements, not interchangeable labels. Verify current documentation and settings for the exact service, plan, region, account, and data type; a broad provider security statement may not answer a product-specific question.
Rank #4
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Apple’s Platform Security guide provides an example of why to separate layers: it describes TLS for data moving between user devices and iCloud servers, an additional encryption-at-rest layer on iCloud servers, and differences for data that is not end-to-end encrypted. Treat this as an illustration of the documented service behavior, not proof that every iCloud data category has identical protection or account options. Check the current service details relevant to your data: Apple Platform Security guide.
Prioritize gaps and keep the inventory current
Review records with sensitive data, internet exposure, an unencrypted or unknown status, unmanaged endpoints, unclear key or recovery ownership, or a critical dependency on one key custodian first. Assign an owner and due date to each unresolved gap. Recheck affected records after operating-system or app changes, cloud configuration changes, device enrollment changes, or changes to key management. There is no universal cross-topic scoring formula established by the sources cited here, so apply a consistent risk rationale suited to your organization.
When evaluating a report or inventory method, note its actual coverage: which platforms and services it sees, whether device enrollment is required, whether it exposes app and cloud configuration, whether evidence can be exported, how fresh the report is, whether it shows key/recovery ownership, and whether a result is observed, inferred, or based only on vendor documentation. A clean status for one tool’s scope should never silently stand in for everything outside it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
