Tangem's Andrey Lazutkin Makes A Case for Simpler Hardware Wallets

Current hardware wallet marketing usually runs in one direction: more features, more screens, more connectivity, more firmware updates. Tangem built its entire product on the opposite bet.
 

There is no screen, no battery, no USB or Bluetooth connectivity, no updatable firmware, and no seed phrase to record. To many in the security community, this may appear to be a list of features expected of a crypto wallet; however, it is actually a list of functionalities deliberately omitted.
 

Yellow Media sat down with Tangem CTO Andrey Lazutkin and pushed hard on exactly that. 

• What happens when the phone is compromised? 
• Why ship a firmware you can never patch? 
• What protects a Tangem Ring from an NFC attack in a crowded train? 
• And what happens when quantum computing arrives?

The screenless problem: what if the phone is lying?

A core principle of traditional hardware wallets is "What You See Is What You Sign" — an on-device screen that lets users verify transaction details. Tangem is screenless and offloads the entire interface to a smartphone. 

If a phone is compromised by malware that alters what's displayed on the screen, a user could authorize a malicious NFC transfer without knowing. How does your architecture prevent UI tampering on an infected host?

A screen is not a security model by itself. It is just one component. But components create risk. The more complex a hardware wallet becomes, the more attack surfaces it has: display logic, buttons, firmware, update mechanisms, USB, Bluetooth, batteries, drivers, parsers, and physical interfaces. 

The internet is full of examples where traditional hardware wallets were attacked not because cryptography was broken, but because implementation complexity created an opening.

Tangem is built on the opposite philosophy: make the signing device as simple as possible. No screen, no battery, no USB, no Bluetooth, no updatable firmware, no complex operating system. The private key is generated and stored inside the secure chip and never leaves the card. That simplicity is a major security advantage.

The phone is used for the interface, but it is not where the keys live. The Tangem app is also heavily protected: 

• runtime integrity checks, 
• anti-debugging,
• anti-emulation, 
• root and jailbreak detection, 
• encrypted storage,
• secure communication, 
• certificate validation, 
• WebView protection, 
• tapjacking protection, 
• secure input handling, 

To top it up, I'll add minimized permissions, code review, audits, and automated security checks.
 

So we don't look at security as "screen or no screen." We look at the entire architecture. Tangem minimizes the attack surface in hardware and hardens the mobile layer that prepares transactions. This approach offers users a powerful combination: a simple, isolated signing device and a secure, modern mobile experience.

In security, complexity is often the enemy. Tangem's advantage is that the card does very little, yet does one critical thing extremely well: protecting the key and signing securely.

Why the card can never be patched

Your firmware is factory-flashed and immutable — it can't be updated over the air, eliminating the risk of malicious firmware updates. But if a zero-day or a critical cryptographic flaw is found in that chip batch later, users can't patch. Why is a completely un-upgradable chip safer for long-term self-custody than a patchable one?

Patchability is not free. In a hardware wallet, an update mechanism is also a permanent code-injection mechanism.

If a wallet can receive new firmware after it leaves the factory, then the user must keep trusting the vendor forever: its signing keys, build system, release pipeline, update servers, employees, security processes, and future business decisions. Even if everything is designed correctly, that infrastructure becomes part of the trusted computing base.
 

This creates real risks: compromised update servers, leaked signing keys, malicious insiders, regulatory pressure, accidental bad updates, or a future firmware change that weakens the original security model.

The Ledger Recover controversy made this very clear. Ledger's own support account reportedly wrote in a now-deleted post: "Technically speaking, it is and always has been possible to write firmware that facilitates key extraction. You have always trusted Ledger not to deploy such firmware, whether you knew it or not." That is exactly the trust assumption Tangem removes.
 

Tangem chooses immutability. Our firmware is flashed during manufacturing and cannot be modified afterward. There is no OTA update, no USB firmware flashing, no wireless update path, and no way for Tangem to push new code to the card once it is in the user's hands.

Yes, this means we cannot patch a chip remotely if a future hardware-level vulnerability is discovered. But an updatable device does not eliminate risk; it creates a different and permanent risk: the ability to change security-critical code later.

For long-term self-custody, we believe the safer root of trust is immutable. The device should not depend on the manufacturer staying trustworthy forever. Tangem's philosophy is simple: the card should protect the key, sign securely, and never accept new code again.
 

The app-store dependency

Tangem depends on its companion app; you have a structural dependency on centralized distribution channels like Apple's App Store and Google Play.

 If a state actor or a sophisticated attacker compromised your developer credentials and pushed a malicious update before your team caught it, what native guardrails inside the secure element protect user funds?

For this scenario to happen, an attacker would need to compromise our developer credentials, bypass MFA and internal access controls, get through the release approval process, inject malicious code into the official build, pass Apple or Google review, preserve the official app identity, avoid platform malware detection, and remain unnoticed by our team, monitoring systems, and the open-source community.

This is not one vulnerability. This is a cascade of failures across multiple independent security layers. And this is exactly what I mean when I say security must be evaluated as a complete system, not by looking at a single isolated feature. 

In our view, the probability of such a chain succeeding is significantly lower than the risks created by a more complex hardware wallet architecture, especially one that depends on firmware updates to remain secure over time.
 

More complex devices need more interfaces, more firmware, more update mechanisms, more components, and more trusted processes. Each of those layers creates additional attack surfaces: supply-chain attacks, debugging interfaces, firmware bugs, malicious or compromised updates, signing-key leaks, build-system compromise, or vendor pressure to change device behavior after shipment.
 

If you look at the history of hardware wallet attacks, this pattern is very clear. Most real-world problems do not come from breaking cryptography. They come from complexity: implementation mistakes, update mechanisms, physical interfaces, firmware behavior, supply-chain assumptions, or unexpected interactions between components.

A malicious app-store update is a theoretical risk. But it requires a chain of independent failures before the attacker even reaches the user. A permanently updatable source code, by contrast, keeps a code-update pathway open by design throughout the product's lifetime.

This is the core of Tangem's security model: minimize the number of trusted components, reduce the attack surface, and make the signing device immutable.

Seedless backup vs. the paper seed phrase

Your seedless architecture maintains security by cloning the private key onto backup cards at setup. That removes the single point of failure of a written seed phrase, but it creates a physical dependency: lose your backup cards, and you hit a recovery wall. How does a hardware-only backup scale for multi-generational inheritance or estate planning compared to traditional BIP-39 paper standards?

When people buy a hardware wallet, they expect the device to protect their private keys. But in many traditional wallets, the device first displays the seed phrase to the user and hands responsibility back to them.
 

From that moment on, the weakest link is no longer the hardware wallet. It is the seed phrase: a piece of paper, a metal plate, a drawer, a safe, a photo someone should never take, or a phrase that can be lost, damaged, copied, exposed, or stolen.
 

Lost access to private keys and recovery phrases is one of the biggest real-world causes of permanent crypto loss. Chainalysis has estimated that millions of bitcoins are permanently lost. Phishing attacks also keep targeting seed phrases directly, because once the phrase is exposed, the price or security level of the hardware wallet no longer matters.
 

In a traditional model, you have a hardware wallet and a seed phrase. You can make more seed copies, but each one increases the risk, since they are not protected by hardware. The user has to invent their own security system.
 

Tangem sees things a bit differently: they believe the backup should also be safeguarded by hardware. That’s why, with a standard Tangem setup, users receive three cards. Each card is a fully capable hardware wallet with a secure element, rather than just an unprotected paper secret.
 

For inheritance or long-term storage, users can keep one card for daily use, store one securely, and give another to a trusted family member, lawyer, or as part of an inheritance arrangement. If all cards are lost, there is no recovery, but that is true self-custody. What Tangem removes is the most fragile part of the traditional model: an exposed seed phrase.
 

If the private key is important enough to protect with a hardware wallet, then its backup should also be protected by a hardware wallet. That is exactly what Tangem does.

Can transaction simulation ever be 100%?

DeFi phishing and blind signing remain dominant ways consumer wallets get drained. Your app integrates transaction simulation and dApp scam detection to show users what a contract will execute. 

But given the Turing-complete nature of complex, multi-hop smart contracts, can client-side simulation ever be 100% reliable? Or does it risk giving users a false sense of absolute security?

That is an excellent question, because you used the key phrase "absolute security."

The honest answer is no. No wallet, simulation engine, hardware device, or security company can promise absolute security. Crypto is an adversarial environment. Security is not one magic feature; it is a set of layers that make attacks harder, more expensive, and less scalable.
 

And sometimes the weakest point is not where people expect it. There are publicly confirmed cases in the industry where customer data from hardware wallet purchases was exposed. In such cases, the issue was not necessarily the cryptography or the device itself, but the broader security perimeter around the user: phishing, social engineering, fake support contacts, fake replacement devices, or targeted pressure.
 

On the DeFi side, Tangem uses some of the most advanced protection layers available: transaction simulation, smart-contract risk analysis, malicious dApp detection, domain checks, warnings around suspicious behavior, and protection against blind signing wherever the transaction can be decoded and analyzed.
 

But can simulation be 100% reliable for every possible smart contract? No. Complex smart contracts, multi-hop routes, changing on-chain state, malicious front ends, phishing domains, and social engineering mean that users still need to verify where they are connecting, what they are approving, and whether they trust the dApp.
 

So we never position simulation as absolute protection. We position it as an additional security layer that dramatically improves visibility before signing. It helps users understand what a transaction is likely to do, detect scams earlier, and avoid blind approvals.

The right mindset is this: Tangem protects the key with hardware, reduces the attack surface with a simple, immutable card, and adds modern DeFi protection in the app. But users should still use trusted dApps, verify domains, avoid rushed or pressured transactions, be careful with approvals, and never treat any warning system as a substitute for common sense.

Absolute security does not exist. Strong security comes from layered defenses — and that is exactly how Tangem is built.
 

Paying gas in stablecoins without breaking cold storage

You recently introduced a feature letting users pay native network fees in stablecoins like USDT or USDC instead of the network's gas token. Under the hood, bypassing native gas mechanisms typically requires account abstraction relayers or third-party liquidity. 

Are these convenience features introducing subtle counterparty risks or centralized dependencies into what is intended to be a cold-storage environment?
 

Tangem uses EIP-7702 for Smart Gas on supported EVM networks. This allows users to pay network fees in some ERC-20 tokens instead of holding the native gas token. It does not change the custody model: the private key remains inside the Tangem card, the user still signs with the hardware wallet, and no third party gets access to the keys.
 

Open-source app, closed-source silicon

Your companion app is fully open source on GitHub, which aligns with the community's "Don't Trust, Verify" ethos. But the EAL6+ secure element inside the cards runs on a proprietary, closed-source architecture developed by silicon manufacturers. 

How do you reconcile the open-source philosophy of DeFi with a hardware foundation that requires trusting a corporate foundry's closed-source design?
 

Open source is important, but saying that every layer of a secure hardware product must be open-source is a very simple way to identify someone who does not understand hardware security.
 

For a secure element, closed low-level firmware and closed chip internals are not a flaw. They are part of the protection model. These chips are designed to resist physical and invasive attacks: fault injection, side-channel analysis, probing, glitching, laser attacks, and other lab-level techniques. Publishing detailed information about internal firmware behavior, memory layout, sensors, countermeasures, or fault-detection logic would not make users safer. It would give attackers a better map.
 

This is not naive "security through obscurity." Serious hardware security is based on layered protection: certified secure elements, limited command sets, independent audits, immutable firmware, and minimal attack surface. 

But it also means not exposing unnecessary low-level implementation details that make physical attacks easier.

And let's be honest: even when someone claims "open-source firmware," the secure chip itself is still not fully open. It contains hardware logic, ROM, microcode, proprietary countermeasures, manufacturing processes, and physical security mechanisms that users cannot realistically inspect or reproduce. 

So, pretending that a consumer can fully verify the entire hardware root of trust because some firmware code is published is misleading.

Our security model is "close it where disclosure would help attackers, independently evaluated where trust is required, and stay as minimal as possible".

Taking the hardware into public: the Tangem Ring

As Tangem expands past cards into consumer wearables like the Tangem Ring, the hardware moves directly into public space. What technical measures protect a user against an adversary using an amplified NFC reader in a crowded environment to attempt unauthorized handshakes or brute-force access codes?

First of all, NFC stands for Near Field Communication. It is designed to work at a very short distance, so the idea of an "amplified reader" silently interacting with a ring on someone's finger in a crowded place is not a realistic everyday attack scenario.

There is also a practical point: Tangem Ring is designed to look like a normal wearable device, similar to payment rings or other consumer accessories. An attacker would first need to identify that the person is wearing a crypto hardware wallet, not just a regular ring.

But even if someone tried to interact with the ring over NFC, that would not give them access to the wallet. Tangem Ring, like Tangem cards, is protected by a user-defined access code. Without that access code, an attacker cannot authorize wallet operations.

Brute force is also not a practical path. The device protects against repeated password attempts: after incorrect attempts, the delay between attempts increases, making automated guessing infeasible.

So the security model is simple: NFC proximity alone is not enough, physical presence alone is not enough, and guessing the access code is not a realistic attack. Users can safely wear Tangem Ring in public.

Regulation and the self-custody core

Global regulators are intensifying frameworks around "unhosted wallets" and mandatory transaction destination screening. As a CTO, are you designing your infrastructure to resist potential future demands for embedded compliance or KYC hooks within self-custody apps — or is your software engineered to be entirely un-modifiable regardless of shifting legal landscapes?
 

First, it is important to separate the device architecture from the regulatory layer.

In Tangem, the private key is generated and stored inside the card. The card does not know what KYC is, does not depend on a compliance server, and does not ask Tangem for permission to sign a transaction. It simply protects the key and signs when the user authorizes it.
 

The user can interact with the card through the official Tangem app, or technically through open-source tools and SDKs. That means Tangem cannot remotely freeze the card, extract the key, or prevent the user from accessing their funds at the hardware level.
 

Now, regarding regulation, I think it is important to be realistic. Forcing self-custody wallets to embed control mechanisms directly into the signing layer would be the wrong tool. There are many free wallets, open-source wallets, forks, and underground solutions. If regulators push users away from secure, audited products, many will simply move to less transparent, less safe alternatives. That would increase losses, scams, and shadow activity, not reduce them.
 

What we already see globally is a different trend: regulators focus on points where crypto touches regulated services; exchanges, on-ramps, off-ramps, payment products, and financial intermediaries. That is where KYC, AML, sanctions checks, and reporting obligations usually belong.
 

If certain jurisdictions require lawful compliance flows for specific services, Tangem can help users remain compliant when using those services. But that is very different from saying that the hardware wallet itself should become a permissioned device.
 

Our position is simple: Tangem may support compliant access to regulated services, but the self-custody core must remain self-custody. The card protects the key. The user controls the funds. Tangem does not hold the assets, does not control the private key, and does not have a remote switch to decide whether a user is allowed to sign.
 

The quantum question

The vast majority of hardware wallets, including Tangem, rely on standard ECDSA or Ed25519 elliptic-curve cryptography. With quantum computing accelerating, how vulnerable is fixed-firmware silicon to eventual quantum decryption, and what is your roadmap for transitioning existing physical cards to post-quantum cryptography?
 

The transition to post-quantum cryptography has to start at the blockchain protocol level.

Hardware wallets do not define which signature algorithms Bitcoin, Ethereum, Solana, or other networks accept. First, blockchains need to adopt post-quantum-resistant cryptographic standards. Only after that can these algorithms be implemented across wallets, secure elements, and signing devices.
 

Today, there is no universally accepted migration path or single post-quantum algorithm adopted by major blockchains for everyday transaction signing. The industry is still researching, testing, and debating the right approach.
 

Tangem is actively working in this direction, but this challenge is much bigger than hardware wallets alone. The same transition will affect banking cards, SIM cards, secure elements, identity documents, IoT devices, and many other security-critical systems.

Over the next few years, we expect strong acceleration in post-quantum cryptography, secure chip support, and blockchain-level standards. When the networks are ready to support these algorithms, Tangem will evolve with them.

The key point is simple: post-quantum migration is an ecosystem-level transition; blockchains first, then hardware wallets.

The through-line across every answer is the same argument Tangem has made since day one: security is a property of the whole system, not of any single feature. Fewer moving parts, fewer things to trust, fewer things that can break, and one critical job done extremely well.