Trezor Model One Legacy Support: When Manufacturers Stop Patching and Users Face Forced Obsolescence

A user who purchased a Trezor Model One in 2015 or 2016 now faces a practical question: the device still powers on, still signs transactions, and the private keys remain offline. Yet Trezor’s developer resources have shifted entirely to the Model T and newer hardware. Security announcements mention firmware versions that will never reach the older device. The question is not whether the device works—it clearly does—but whether it remains trustworthy once the manufacturer stops releasing patches, and whether “still working” is the same as “still secure.”

This problem has become acute because hardware wallet obsolescence differs fundamentally from software obsolescence. A smartphone or laptop can become unsupported while still functional, and users accept that risk as part of the product lifecycle. A hardware wallet, by contrast, exists precisely to isolate private keys from a network-connected device. The irony is that once a manufacturer stops patching firmware, users face a choice between accepting unpatched security issues in a device they trusted with long-term asset storage, or migrating to newer hardware—a process that carries its own risks if not executed carefully. Understanding what actually happens to security and risk when a crypto hardware wallet device reaches end-of-life is essential for anyone holding significant value in older models.

Understanding Trezor’s actual firmware support timeline

Trezor publishes security advisories when vulnerabilities are discovered and fixed. Reviewing those announcements reveals the practical support boundaries. The Model One received regular firmware updates through approximately 2021, after which the focus shifted almost entirely to the Model T and newer devices. This does not mean Model One updates ceased immediately or completely; rather, the cadence slowed and the developer attention diminished. Critical security issues may still receive patches, but routine improvements, protocol upgrades, and feature additions went to newer hardware.

The firmware update mechanism itself matters here. Model One users connect their device to a computer running Trezor Suite—available as desktop or web-based application—and firmware updates are delivered and installed through that interface. The process is relatively straightforward: the device prompts the user to confirm the update, displays the firmware hash on the hardware screen for verification, and installs the signed binary. Because the update is cryptographically signed by Trezor, users cannot accidentally install malicious or corrupted firmware.

However, the cessation of updates creates a boundary condition. Trezor’s decision to stop releasing Model One firmware patches was not announced as a hard date; instead, it emerged gradually as newer versions of Trezor Suite began requiring newer firmware, and as security advisories explicitly stated that certain vulnerabilities were fixed only in the T or T2 models. Users running older firmware versions found themselves unable to benefit from those fixes. The company’s commercial incentive is obvious: pushing users toward new hardware generates revenue, while supporting obsolete devices indefinitely does not.

For a user evaluating whether to keep or replace a Model One, the relevant information is what vulnerabilities remain unfixed. Trezor’s security advisories can be reviewed to identify issues affecting the older model specifically. This requires reading each bulletin carefully rather than assuming that “security fix released” applies uniformly to all models. Some advisories address the Model One, some address later models, and some affect the entire ecosystem.

What firmware vulnerabilities actually mean for offline key storage

The threat model for a hardware wallet is narrower than for a typical computer because private keys never leave the device. A firmware vulnerability in Trezor’s Model One could theoretically allow an attacker to extract the seed phrase, forge signatures, or compromise the device’s cryptographic operations. However, “could allow” depends entirely on how the attacker would exploit the vulnerability in practice. A Model One sitting on a desk, unplugged except during periodic transactions, has a very different threat surface than one connected to a compromised computer.

Consider a concrete example: if a vulnerability existed that allowed extracting the seed phrase during a firmware update, an attacker would need to either have physical access to the device during that update, or have compromised the user’s computer before the update was installed. Neither is a passive or remote attack. The device’s design principle—keeping private keys offline—means that many categories of malware and network-based attacks cannot reach the cryptographic material directly.

That said, “offline” is not absolute. During a transaction, the device must communicate with Trezor Suite to receive the transaction details, verify amounts and addresses, and return a signed transaction. If a firmware vulnerability allowed an attacker to manipulate this communication or bypass signature verification, the offline design no longer protects the user. The question then becomes: how likely is it that such a vulnerability exists in unpatched firmware, and how likely is it that an attacker would exploit it against a specific user?

For a Model One that has not received firmware updates in several years, the answer is that no one can be certain. Security researchers may have discovered and disclosed vulnerabilities since the last update. If those vulnerabilities were fixed in newer firmware but not disclosed widely outside of Trezor’s advisory system, a Model One user would not know whether their device is affected. This uncertainty is the actual cost of legacy support ending: not a guarantee of compromise, but a loss of visibility into what risks remain.

The migration dilemma and its own security risks

When faced with an unsupported device, many users consider replacing it with newer hardware. This creates a second problem: the migration process itself must be executed carefully, or it can introduce new risks. The most secure approach is to treat the Model One as if it might already be compromised, and to therefore avoid exposing the recovery phrase during migration.

The proper procedure involves creating a new seed phrase on the new device and then gradually consolidating funds. Specifically: set up the new hardware wallet and generate a fresh seed phrase. Do not attempt to import the old Model One’s recovery phrase into the new device through any import function, even if such a function exists. Instead, from the Model One, send the cryptocurrency to a fresh address on the new device. Do this in stages if the balance is large, using separate transactions to different addresses to reduce the size of each movement. Crucially, the old recovery phrase never needs to be written down, spoken aloud, or exposed to another device during this process.

The alternative—importing the old Model One recovery phrase directly into new hardware—is tempting because it preserves the original cryptographic identity and derived addresses. However, if the Model One’s firmware was already compromised, importing its seed into the new device could compromise the new hardware immediately. Abandoning the old seed phrase and moving to new addresses is slower and more tedious, but it is the correct risk mitigation when replacing potentially vulnerable hardware.

This migration procedure also requires accepting a practical reality: the old Model One can never be fully retired until the consolidation is complete and verified. The user must retain the device long enough to confirm that all funds have been successfully moved. During that period, the old device must be stored securely and checked periodically to ensure no unexpected transactions appear. Only after a reasonable confirmation period should the Model One be considered fully decommissioned.

Comparing legacy Model One to active-support newer models

The Trezor ecosystem now centers on the Model T and more recent devices, which continue to receive firmware updates and security patches. A user deciding whether to upgrade can compare the concrete differences. Model T added a touchscreen for address verification, a larger display for more complex information, and support for additional blockchains and tokens. From a security perspective, the T uses a more powerful processor and a different architecture that may reduce certain attack vectors that affected the Model One.

However, “newer hardware is more secure” is not universally true. The Model One’s simplicity—smaller screen, fewer features, narrower scope—means fewer code paths that could contain vulnerabilities. A complex touchscreen system has more potential attack surface than a simple button interface. The relevant comparison is not simply “old versus new” but “known-unfixed vulnerabilities in Model One versus unknown potential vulnerabilities in newer hardware, offset by the fact that newer hardware receives active patching.”

Upgrading also creates a transition period where both devices must be managed. The user needs to keep the old device secure, track its status, and eventually migrate funds. For someone with a substantial balance, this is not a quick weekend project. It requires careful documentation, verification at each step, and retention of both devices until the consolidation is complete and tested.

The upgrade decision should also account for the total cost of ownership. A genuine crypto hardware wallet like the crypto hardware wallet involves not just the purchase price but also the time and operational complexity of setup, migration, backup management, and future support. For a user with a relatively small balance and long holding periods, the costs of migration might exceed the security benefit of upgrading to newer hardware that receives patches.

What “security” actually means for a device without patches

A critical misunderstanding is that unpatched firmware is automatically unsafe. In reality, security is contextual. A Model One sitting in a safe, powered off except during infrequent transactions, used on an air-gapped or dedicated computer, with no network connection to the device itself, presents a different risk profile than the same device being actively used on a shared computer infected with malware.

Firmware vulnerabilities broadly fall into categories. Some allow privilege escalation—an attacker who already has some access gets more. Others allow seed phrase extraction if an attacker can manipulate the update process. Some affect transaction signing under specific conditions. A vulnerability that requires physical access is different from one exploitable remotely. A vulnerability exploitable through Trezor Suite is different from one requiring custom hardware equipment.

The practical security of an unpatched Model One depends on whether any unfixed vulnerability is relevant to the user’s threat model. For someone holding Bitcoin long-term without frequent transactions, using the device rarely and carefully, the marginal risk from an unfixed firmware vulnerability may be acceptable. For someone making frequent trades or payments, or for someone with a very large balance, the risk accumulates—more transactions mean more opportunities for an attacker to observe patterns, more exposure through Trezor Suite interactions, and a larger potential loss if something goes wrong.

There is also the question of what “unfixed” actually means. Some vulnerabilities may be public knowledge, described in security advisories or academic papers, but not yet widely exploited. Others may exist but not be known to anyone outside Trezor’s security team. This asymmetry of information is precisely why hardware manufacturers typically maintain some level of support for older devices: users deserve to know about vulnerabilities that affect the devices they trust with their assets.

The manufacturer’s incentives and the user’s obligations

Trezor, like all hardware manufacturers, has commercial incentives to migrate users to newer products. Continuing to support old hardware indefinitely is costly and generates no revenue. At some point, supporting a device from 2015 becomes impractical when the engineering team could be working on new features for newer products. This is economically rational, even if it is not ideal from a user-support perspective.

However, the transition from active support to legacy status should be transparent and deliberate. Users should receive clear communication: “We will stop releasing firmware updates for the Model One on [date].” Instead, the shift happens gradually, and users discover it only when they realize that security advisories no longer mention their device, or when Trezor Suite adds a requirement that their firmware no longer meets.

The user’s obligation, then, is to take this transition seriously. Checking Trezor’s security advisories periodically, monitoring for the last firmware version released for your model, and planning a migration strategy before you need it under pressure—these are the practices that separate informed users from those who discover they own obsolete hardware only when a problem emerges.

One additional consideration: the open-source nature of Trezor’s firmware means that community security researchers could, in theory, audit the Model One codebase and identify unfixed vulnerabilities. The community could even develop patches. However, users cannot install community-patched firmware on their Model One because the device verifies that firmware is signed by Trezor’s keys. This design prevents malicious firmware from being installed, but it also means that end-of-manufacturer-support is truly the end. No workaround exists to continue receiving security improvements from the community.

Practical guidelines for Model One users holding significant value

For someone holding a substantial balance in a Model One, the approach should be deliberate rather than reactive. First, document the current state: note the firmware version, the number of addresses with balances, the total value, and the date of the last transaction. This establishes a baseline for monitoring whether anything unexpected occurs.

Second, create a migration plan before you need it. Decide whether to upgrade to a Model T or another newer device, or whether your risk tolerance and usage pattern support keeping the Model One in place indefinitely. If upgrading, set a target date and begin learning the process. Small test transactions should be executed first: send a small amount of cryptocurrency to a fresh address on new hardware and verify that the receiving address matches what was displayed on both the old and new devices.

Third, if you choose to migrate, treat the old seed phrase with even greater security than before. The recovery phrase becomes a “fallback” only, to be used if the device fails completely and you have no alternative. During the consolidation period, check the old device periodically to ensure no unauthorized transactions appear. If any movement occurs that you did not initiate, treat it as a sign of compromise and accelerate the migration.

Fourth, understand that “keeping the Model One safely” requires ongoing discipline. The device should be stored securely, protected from physical damage, and kept in an environment where the firmware cannot be accidentally updated to something malicious. Avoid connecting it to suspicious computers or networks. If you use it frequently, apply the same security practices you would for new hardware: verify addresses on the device screen, confirm amounts before approving transactions, and maintain careful records of transactions for auditing purposes.

The broader question of hardware wallet longevity and responsibility

Trezor’s decision to end support for the Model One raises a systemic question: how long should manufacturers support cryptocurrency hardware wallets? Unlike software applications, where a new version can be updated over the internet at no cost to the user, hardware wallets require users to make a deliberate choice to upgrade, and that choice carries migration risks.

The answer is probably nuanced. A manufacturer cannot support every device forever; engineering resources are finite. However, transparency and a defined transition period are reasonable expectations. Users should know when support is ending, what vulnerabilities were fixed in newer firmware, and whether older devices remain safe for basic use. The current situation—where support gradually fades and users discover obsolescence only by reading between the lines—is worse than either extreme.

For Trezor users specifically, the lesson is to treat your hardware device as a durable good with a finite support window. Monitor security advisories, plan for eventual replacement, and execute migrations carefully when the time comes. A Model One that still powers on and signs transactions is not automatically unsafe, but it is no longer receiving the manufacturer’s assurance of security. Whether that matters depends on your threat model, your value at stake, and your ability to execute a careful migration if needed.