Introduction

Security is often treated as a final stage. A checklist item to be marked as “done” once a product passes a penetration test or obtains a certificate of compliance with an industry standard such as IEC 62243 or Common Criteria.

But true security does not begin at the end. It must be embedded into the architecture, design, and operations of a system from the very first day. This is especially true when products are expected to meet evolving requirements for compliance, auditability, and long-term resilience.

This reality is increasingly reflected in today’s regulatory environment. New legislation such as the Cyber Resilience Act (CRA) and the Radio Equipment Directive (RED) Delegated Act sets general expectations for security throughout the product lifecycle. At the same time, there is growing pressure to follow established industry standards like IEC 62443, which help translate regulatory goals into engineering practice.

In this era of growing security regulations, the role and functionality of secure elements deserve particular attention. When properly designed and thoughtfully integrated, they can become a key factor in strengthening the overall security of a system. This applies especially when they are not treated as isolated components, but as elements embedded in the broader lifecycle of the product. Their role should extend beyond basic encryption or key storage to enable secure boot, firmware validation, update mechanisms, and controlled decommissioning.

This article examines how TROPIC01, an open-source secure element developed by Tropic Square, supports these goals. It serves as a concrete example of how security capabilities can be aligned with compliance requirements throughout the entire product lifecycle.

Why Context Matters in Security Architecture

Security technologies are not always inherently effective. Their true value depends on how well they align with the environment in which they are used.

A secure element with features such as secure key storage, tamper resistance, and cryptographic acceleration may appear robust. However, if it is deployed without a clear understanding of the surrounding system, including its threat model and compliance requirements, these capabilities can be misapplied or left unused.

To ensure proper alignment with the system and to evaluate how a secure element can be used effectively, it is often beneficial to rely on established frameworks and domain-specific standards. The IEC 62443 family of security standards offers structured guidance and multiple perspectives. They also support secure integration throughout the product lifecycle.

Context in this case has two dimensions. One relates to the design of the secure element itself. The other concerns how that secure element is used as part of a broader system. Security decisions must be made at both levels. A well-designed chip is not enough if it is poorly integrated. At the same time, strong system design cannot compensate for a component that lacks transparency or lifecycle support.

Understanding this dual perspective is essential. It allows us to move from isolated features to meaningful security that holds up over time and under scrutiny.

Risk Assessment and the Role of Threat Modeling

Security always starts with understanding risk. Before any specific mechanism can be considered effective, it must be evaluated in the context of what it is supposed to defend against.

Threat modeling plays a key role in this process. A threat model identifies critical assets, potential attack vectors, and expected system behavior under both normal and adversarial conditions. A well-structured threat model is essential not only for secure system integration, but also for the design of the security components themselves.

This duality is important. A secure element can only provide relevant protection if its design reflects real-world threats. At the same time, even the most capable secure element cannot deliver value if the device it is part of does not use it properly.

Manufacturer Perspective

From the perspective of chip design, threat modeling helps define what protections need to be implemented in hardware. For example, should the element detect physical tampering? Should it support secure key derivation or monotonic counters? These answers depend on the types of attacks expected in the target domain.

Chip designers must determine the primary use cases for a secure element to ensure their design properly supports the required functionality. Some of the considerations include:

• What encryption algorithms must be supported (ECC, AES, RSA, PQC, etc.)
• What hash algorithms must be supported
• What interfaces are supported, and what protocol is used to securely communicate with the chip
• How much storage is provided by the chip, and how much of this storage is available for applications using the chip vs. internal storage
• What physical protections are provided by the chip

Hardware Wallet Use Case

The initial use case for the TROPIC01 secure element was in the development of a hardware crypto wallet. There is a critical need for advanced security for crypto wallets. The risks are staggering. Over $2.2 billion was stolen in crypto attacks during 2024 alone, with more than 410 incidents targeting the cryptocurrency sector. Hardware wallets face particularly dangerous threats from cryptostealer malware, which has surged by 56% across all platforms, and sophisticated blind signing attacks that allow transaction manipulation.

The TROPIC01 secure element was developed in response to these threats. One critical requirement of the TROPIC01 threat model is providing strong anti-tamper/physical security protections. As a result, the TROPIC01 provides protection against a wide range of physical attacks including glitching attacks, laser and EM fault injection attacks, micro-probing attacks, and side channel attacks.  

To enable support for hardware wallets, the TROPIC01 provides a trusted security perimeter for cryptographic operations. Within this security perimeter, the TROPIC01 chip provides support for:

• 237 kB of user accessible storage, much more than most traditional hardware secure element chips
• ECC Keys pair generation or secure key provisioning  
• Protected keys storage
• Transaction signing
• Patent-pending PIN-based secrets management for user authentication
• Device attestation

This allows TROPIC01 customers to implement features and applications like: secure boot, secure firmware update, keys management, user verification and authentication, digital signing of transactions and data, and signatures verification with immutable public keys.

System Integrator Perspective

From the system integration perspective, threat modeling guides how the secure element is used. It informs decisions about key provisioning, update verification, root-of-trust anchoring, and decommissioning procedures. These aspects are critical for ensuring that the secure element contributes to lifecycle security rather than functioning as an isolated cryptographic feature.

For example, the TROPIC01 is factory provisioned with a unique ID and signed certificate to allow verification of the authenticity of the chip, and can be provisioned with a code validation key for a specific OEM to enable secure boot and secure firmware updates

By considering both perspectives — design and deployment — threat modeling ensures that security is not generic. It becomes purpose-built, measurable, and traceable. It also aligns technical decisions with compliance expectations, particularly in standards that explicitly require risk-based development such as IEC 62443.

Making Security Observable: Why Transparency Matters Throughout the Product Lifecycle

Security is not a fixed state. It must be verified, monitored, and adapted as the product evolves. In each phase of the lifecycle designers, testers, auditors, and operators must be able to understand what security mechanisms are in place and how they behave under real conditions.

Transparency makes this possible. It allows stakeholders to observe and evaluate the system instead of relying on assumptions. For secure elements, this is especially important. These components are often expected to serve as the foundation for trust but are commonly delivered as opaque and unverifiable.

Transparent design enables independent testing during development. It also supports repeatable validation in production and meaningful audit trails during deployment. In later stages, such as maintenance and decommissioning, transparency helps verify that updates have not introduced unexpected changes and that keys have been properly destroyed.

Without this visibility, it becomes difficult to prove that the system is still secure. Even a well-designed secure element can become a point of failure if its behavior cannot be inspected or verified throughout its lifecycle. Worse still, without being able to inspect the design of the secure element, developers and testers cannot verify that the product is free from security vulnerabilities, undocumented features, or hidden back doors.

In this context, transparency is not just a matter of philosophy. It is a practical requirement for enabling lifecycle security. It turns secure elements from isolated devices into traceable and accountable components that support long-term assurance and compliance.

From Concept to Reality: Security as a Continuous Process

Secure elements can play a critical role in building secure and compliant systems. But they only fulfill this role when they are understood and applied as part of a larger process.

This process begins with understanding risk and context. It continues through design, integration, operation, and decommissioning. At each step, decisions must be guided by clear objectives, supported by standards, and grounded in reality.

Transparency makes this process visible. Threat modeling gives it structure. And lifecycle thinking keeps it connected across time, teams, and systems.

Security is not something that can be added at the end. It cannot be reduced to a specification, a checklist, or a certificate. It must be shaped into the product from the beginning and carried through its entire existence.

Only then can components like secure elements become more than cryptographic tools. They become trusted building blocks that support long-term resilience, compliance, and confidence.

‍