Key Takeaways
- Hardware AES, key never leaves the controller. AES-128/256 runs inside the SSD controller. The plaintext Media Encryption Key (MEK) exists only inside the controller and only while powered — never in the host CPU, DRAM, or NAND. The standard cold-boot DRAM extraction path used against software-encrypted systems does not apply.
- TCG Opal 2.0 for unattended edge nodes. Credential-based unlock, multiple Locking Ranges, and Shadow MBR pre-boot authentication keep the OS image inside a locked range unreadable until valid credentials are supplied.
- Cryptographic erase for field decommissioning. Destroying the MEK renders all previously stored data unrecoverable — fast enough to use in the field, and qualifies as a NIST SP 800-88 Rev. 1 “Purge” sanitization when implemented per the drive’s documented key-handling procedure.
- Hardware overhead is bounded, not zero. The AES engine adds a small amount of latency on each I/O. Because it runs on dedicated silicon inside the controller rather than the host CPU, the overhead is predictable and substantially smaller than the CPU tax of software encryption — but it is not zero. Tight performance budgets should be validated against the actual application profile.
- ATP SecurStor extends protection across the lifecycle, on a project basis. Anti-cloning, configurable Write Protect / Read-Only ranges, Quick & Secure Erase, hidden areas, and other application-specific safeguards. SecurStor is a project-based security customization — specific features, configurations, and scope are agreed per engagement, not enabled as a fixed list on every SKU.
TCG Opal 2.0 Primer
The TCG Opal Security Subsystem Class (SSC) is a set of specifications for self-encrypting drives (SEDs) developed by the Trusted Computing Group (TCG), a non-profit organization that develops, defines, and promotes open standards and specifications for secure computing.
The Opal SSC, currently available in version 2.0, presents a hierarchy of security management standards to secure data from theft and tampering by unauthorized persons who are able to gain access to the storage device or host system where the storage device resides.
What are Opal 2.0-Compliant SEDs?
Self-encrypting drives (SEDs) supporting Opal 2.0 use hardware encryption technology to secure data stored in them. By encrypting the entire drive, users do not have to worry about their data being accessed if the drive, laptop or mobile device gets stolen or lost.
An Authentication Credential (which may be derived from a password, passphrase or other authentication mechanism) is used to generate a Key Encryption Key (KEK), which encrypts the Media Encryption Key (MEK) before it is stored in the SED. The MEK is generated internally in the SED and is persistently stored in encrypted form; its plain text is kept only within the SED controller and only while the SED has power. When the SED no longer has power, the MEK plain text is lost, rendering the drive “locked.”
Upon power on, the user supplies a password, passphrase or other authentication mechanism, from which the host application generates an Authentication Credential. This credential is then sent to the SED to unlock the drive and provide access to the data. If the credential provided is correct, a Key Encryption Key (KEK) decrypts the encrypted MEK, which can then encrypt/decrypt data.
According to a joint whitepaper released by the Trusted Computing Group and NVMe Express, storage devices implementing Opal “are built to protect the confidentiality of stored user ‘Data at Rest’ (DAR) against unauthorized access once it leaves the owner’s control, when or after the storage device has been power cycled.”
Advantages of Opal 2.0-Compliant ATP SATA & NVMe™ Drives
ATP’s next generation SATA and NVMe drives comply with the Opal 2.0 standard, ensuring a secure layer of protection for data at rest. These SEDs offer several benefits and advantages over software-based encryption:
- No Performance Degradation. In contrast to software encryption, hardware encryption frees the CPU or operating system from the load of the encryption/decryption process, so there is no degradation in overall performance.
- OS-Independent Security. Attackers can exploit vulnerabilities in the operating system by executing malicious code. SEDs perform encryption within the drive controller and do not store encryption keys in the host processor or memory, which can be attacked by hackers. Additionally, user authentication is performed within the SED before the drive is unlocked, so threats coming through the OS will not work.
- Encryption Management-Free Protection. SEDs automatically generate the Media Encryption Key (MEK) internally and therefore does not require encryption key management. The self-generated key stays with the drive, making stored data inaccessible even if the drive is stolen or lost. Data can be read from and written to the SED only after the correct key has been supplied.
Figure 2. Opal Device layout: The user area is always encrypted with a Media Encryption Key (MEK). The MEK is encrypted/decrypted with a Key Encryption Key (KEK). The user area may be subdivided into different zones with different keys, locked/unlocked and cryptographically erased independently from others, and may have different users assigned with lock/unlock permissions). (Image reference/source: Trusted Computing Group and NVM Express Joint White Paper: TCG Storage, Opal, and NVMe)
How Industrial SSDs Protect Sensitive Edge Data from Unauthorized Access
At the edge — remote IoT gateways, kiosks, in-vehicle systems, surveillance nodes, smart factory controllers, unmanned outdoor cabinets — storage devices sit in places where they can be physically reached, removed, or powered off by someone without IT supervision. That changes the threat model in two ways. The drive itself becomes a target, not just the data flowing through it. And recovery from a compromise is slow, because there is rarely anyone on-site to respond. Industrial SSDs answer this by combining TCG Opal 2.0-compliant hardware encryption with firmware- and silicon-level safeguards that keep sensitive data confidential even if the device is removed from the system, powered off, or physically tampered with.
The first line of defense is always-on AES-128/256 hardware encryption performed inside the SSD controller. The plaintext MEK exists only inside the controller and only while the drive has power — it is never present in the host CPU, DRAM, or NAND in unencrypted form. The standard cold-boot extraction path used against software-encrypted systems — pulling keys from host DRAM — therefore does not apply. Without valid credentials, the encrypted MEK stored on NAND cannot be unwrapped, and the user-area ciphertext cannot be decrypted within any practical computational budget.
ATP works at a deeper level than a typical reseller of reference-design firmware. Through the controller vendor’s Firmware Development Kit — and, where the engagement allows, with source-level access and development tools — ATP customizes how the drive behaves in the cases that decide an industrial deployment: power-loss recovery, authentication state transitions, locking range boundary behavior, and the surrounding key-handling sequence. The depth of FDK or source access varies by controller and by project, so customization scope is set per engagement. Customized firmware is then validated on ATP’s own test equipment. The result is that the firmware behavior in the cases that matter is characterized for the deployment, not inherited from a reference design.
Edge devices typically reboot unattended after a power loss, so pre-boot authentication via TCG Opal’s Shadow MBR enforces credential verification before the locked OS range can be read. The OS image inside that locked range cannot be read, modified, or replaced without valid credentials. (PBA does not, on its own, protect against an attacker overwriting the Shadow MBR area itself or replacing the entire drive — defenses against those threats live higher up the stack, in secure boot, drive-bay tamper detection, or chassis interlocks.) Multiple Locking Ranges then let administrators segment system logs, device configuration, and customer payloads under separate keys and user roles — useful when a single edge appliance hosts mixed-sensitivity workloads or serves multiple tenants.
When an edge device reaches end-of-life or has to be field-swapped, cryptographic erase destroys the MEK and provisions a new one, rendering all previously stored data unrecoverable — without the cost and logistics of physically shredding the drive. The method qualifies as a NIST SP 800-88 Rev. 1 “Purge” sanitization when implemented per the drive’s documented key-handling procedure, and is a useful capability for meeting data-disposal requirements under frameworks such as GDPR (Article 17), HIPAA where applicable, and IEC 62443 for industrial control systems.
It is worth being explicit about what an SED does not protect against. Once a user has authenticated and the OS is up, the drive is open to whatever — or whoever — is running on the host. If the host is compromised post-boot, the encrypted-at-rest posture provides no additional defense. This is the gap left by every standards-compliant SED, and it is the layer ATP SecurStor is designed to address: anti-cloning, configurable Write Protect / Read-Only ranges, Quick & Secure Erase, hidden areas, and other application-specific safeguards. SecurStor is offered as a project-based security customization — specific features, configurations, and the products they apply to are scoped per engagement rather than enabled as a fixed list on every SKU. SecurStor does not eliminate the post-authentication exposure window — nothing inside the drive can — but it narrows the surface area available to a compromised host and constrains what the drive itself will accept.
Where an SED may not be the right call. For edge devices that store no sensitive data, or where the host platform already provides strong file-system-level protection and physical access is tightly controlled, an Opal SED can be more capability than the deployment needs. The case for hardware-encrypted SEDs is strongest in unattended, physically exposed environments where post-deployment re-specification is costly — which is most of the verticals ATP serves, but not all.
Security Features
Opal 2.0-compliant storage devices come with the following features:
- Encryption: Hardware encryption of user data supporting AES-128/256 standard (no user interaction required).
- Credentials: Provisioning and configuration using Admin credential; support for multiple user credentials, which can be assigned to perform various actions.
- Locking Ranges: The storage device may be subdivided into multiple "Locking Ranges," each of which is a range of contiguous logical block addresses (LBAs). Each Locking Range may be encrypted with a different MEK and may be unlocked independently of others. Permission to unlock Locking Ranges may be assigned to zero or more users.
- Cryptographic Erase. This refers to the process of destroying a MEK and generating a new one, which means that the data encrypted with that MEK can no longer be decrypted. Locking Ranges may be cryptographically erased independently of the others. Permission to cryptographically erase Locking Ranges may be assigned to zero or more users, providing a fast and secure way to repurpose the drive or perform end-of-life operations. This feature is available as part of ATP’s SecurWipe featureset.
- Master Boot Record (MBR) Shadowing Support. The host application can store and execute a “Pre-Boot Authentication (PBA) Environment” to unlock the range in which the OS is stored so that the OS can boot.
ATP SecurStor: Protection Beyond Opal and AES
An Opal-compliant SED offers several advantages in effectively preventing unauthorized data access due to the loss or theft of the drive or a system that integrates the drive. However, it is not designed to protect data from a breach that occurs after the drive has been unlocked with valid authentication credentials with the OS and applications already launched. If the authorized user has not yet been de-authenticated by the system through a power cycle, the drive remains vulnerable and therefore requires other security mechanisms to keep it protected from unauthorized access.
ATP SecurStor provides a multi-level security suite that protects data with a variety of options beyond data-at-rest encryption and pre-boot authentication. Customers can choose from features that can be customized according to their application-specific requirements to guard against unauthorized access, illegal copying and other security threats to ensure data, OS and firmware integrity at all times.
Frequently Asked Questions
Q1: What is the difference between hardware encryption and software encryption on an industrial SSD?
A: Hardware encryption is performed by a dedicated AES engine inside the SSD controller using AES-128 or AES-256. It runs continuously, adds a bounded amount of latency on dedicated silicon, and never exposes the plaintext MEK to the host CPU, OS, or DRAM. Software encryption runs on the host CPU and operating system — it consumes CPU cycles that would otherwise serve the application, and the keys live in host memory, which is reachable by cold-boot attacks, memory dumps, and OS-level malware.
For unattended edge devices that may store sensitive data and are physically exposed, hardware encryption via a TCG Opal 2.0 SED is the recommended baseline. For edge devices that do not store sensitive data, or where the host platform already provides strong key isolation and physical access is tightly controlled, software encryption — or no encryption at all — may be adequate. The SED’s value depends on whether the threat model actually includes drive removal or unattended physical access.
Q2: Why is TCG Opal 2.0 important for edge and IoT deployments?
A: TCG Opal 2.0 standardizes how self-encrypting drives handle authentication, key management, locking ranges, and cryptographic erase — which matters more at the edge because the device cannot easily be brought back to a controlled environment to be reprovisioned. Pre-boot authentication via Shadow MBR means an unattended device can require credentials before the OS image in a locked range becomes readable. Multiple Locking Ranges let logs, configuration, and customer data be segregated under separate keys. Cryptographic erase enables field-level decommissioning without shipping the device back to a data center.
Q3: Can data on an industrial SSD be recovered after a cryptographic erase?
A: No. Cryptographic erase destroys the Media Encryption Key inside the SSD controller and provisions a new one. Because the user data was only ever stored on NAND in encrypted form, the ciphertext can no longer be decrypted within any practical computational budget. The process completes in seconds and qualifies as a NIST SP 800-88 Rev. 1 “Purge” sanitization when implemented per the drive’s documented key-handling procedure — faster and more operationally reliable than overwriting or physical destruction.
Q4: How does ATP SecurStor extend protection beyond TCG Opal 2.0?
A: TCG Opal 2.0 protects data at rest, only while a drive is locked. Once a user authenticates and the OS boots, the drive is open to whatever is running on the host. ATP SecurStor adds protection across configuration, runtime, and the device lifecycle: anti-cloning, configurable Write Protect / Read-Only ranges, Quick & Secure Erase, hidden areas, and cryptographic erase via external command. SecurStor is a project-based security customization — features and configurations are scoped per engagement to match each deployment’s threat model, rather than offered as a fixed feature set on a specific product line. Customers exploring SecurStor for an edge or industrial program should engage ATP early so the right combination can be defined alongside the design-in. SecurStor does not eliminate the post-authentication exposure window — nothing inside the drive can — but it narrows the surface area available to a compromised host and constrains what the drive itself will accept.
Q5: Do TCG Opal 2.0-compliant industrial SSDs slow down read/write performance?
A: There is a small overhead. The AES engine inside the SSD controller is always active — encryption is not a separate on/off mode on an SED — and adds latency on each I/O. Because that work runs on dedicated silicon inside the controller rather than the host CPU, the impact is bounded and predictable, and substantially smaller than the CPU tax software encryption imposes on the host. The exact difference depends on controller, NAND, queue depth, and access pattern; for performance-sensitive deployments, validate against the actual application profile.
