A secure element is a tamper-resistant hardware platform capable of securely hosting applications and storing confidential data — protected from physical attacks at the transistor level.
A secure element (SE) is a dedicated, tamper-resistant integrated circuit that provides a secure execution environment for sensitive applications and data. Unlike general-purpose processors, a secure element is designed from the ground up to resist both logical and physical attacks — including side-channel analysis, fault injection, and invasive probing under an electron microscope. The hardware enforces strict isolation between the secure domain and any host system it communicates with.
It is important to distinguish secure elements from superficially similar technologies. A Trusted Platform Module (TPM) is a standards-based chip primarily designed to store cryptographic keys and attest system integrity, but it is not designed to execute arbitrary application code in a secure container. A Hardware Security Module (HSM) is a high-assurance server-side device used in enterprise and data-centre environments — far too large and expensive to embed in a consumer card or IoT device. A Trusted Execution Environment (TEE) such as ARM TrustZone is a software-isolated partition within a general-purpose processor; it offers stronger isolation than a normal OS process, but it shares the same silicon die as untrusted code and cannot match the physical tamper resistance of a dedicated chip.
Secure elements are certified under internationally recognised security evaluation schemes — most prominently Common Criteria (CC) at EAL4+ or EAL6+, and EMVCo for payment applications. These certifications require independent laboratory testing of both the hardware and the operating system against a published security target, giving product manufacturers and end users a verifiable, standards-based assurance of the security properties.
| Feature | Secure Element | TPM | HSM | TEE |
|---|---|---|---|---|
| Security Level | EAL4+–EAL6+, CC certified | EAL4, TPM 2.0 | EAL4+, FIPS 140-2/3 | Varies, software-defined |
| Form Factor | Smart card / embedded chip | Discrete chip on board | PCIe card / appliance | CPU partition (no chip) |
| Certification | CC, EMVCo, GlobalPlatform | TCG TPM 2.0 | FIPS 140-2/3 | None standardised |
| Programmability | JavaCard / native C applets | Fixed command set | SDK-based | Full OS-level code |
| Typical Use | Payment, identity, crypto wallet | Platform attestation | Server key management | Mobile DRM, banking apps |
Secure elements have become the foundational trust anchor across a remarkable range of industries, precisely because their security properties are hardware-enforced and independently verified. Wherever an application must prove it holds a secret without revealing that secret — and must continue to prove this even in the hands of a determined adversary — a secure element is the right technology.
In the payment sector, every contact and contactless EMV transaction relies on a secure element to generate a unique cryptogram per transaction, making card cloning computationally and physically infeasible. In the digital identity domain, electronic passports (ePassports conforming to ICAO 9303) store the holder’s biometric data in a secure element and enforce access control through the Basic Access Control and Password Authenticated Connection Establishment protocols. Cryptocurrency hardware wallets use secure elements to ensure private keys are generated and used exclusively inside the chip, so the host computer never touches the key material.
Payment Processing
EMV chip cards, unique transaction cryptograms, anti-cloning protection at the hardware level.
Digital Identity
ePassports, national eID cards, eIDAS qualified signatures — biometric data secured in tamper-resistant silicon.
Cryptocurrency & Blockchain
Hardware wallets, private key isolation, transaction signing — keys never leave the secure element.
IoT Device Security
Device attestation, secure boot, encrypted communication for connected devices at scale.
Automotive
V2X communication authentication, secure over-the-air updates, and digital key management.
Healthcare
Provider authentication, patient data access control, and secure medical device identity.
Cryptnox builds its products on the NXP JCOP P71 — a Common Criteria EAL6+ certified secure element that forms the hardware foundation of the NXP SmartMX3 family. The P71 supports both the JavaCard 3.0.5 virtual machine and a native C development path known as SecureBox, giving development teams the flexibility to choose the programming model that best fits their application’s performance and security requirements.
Standard JavaCard development targets the GlobalPlatform card environment. Applets are written in a
subset of Java, compiled to JavaCard bytecode, converted to a load file, and installed onto the card using the GlobalPlatform Secure Channel Protocol (SCP02 or SCP03). The JVM provides memory safety and applet firewall isolation, preventing one applet from accessing another’s data. The standard cryptographic API covers symmetric ciphers (AES-256, 3DES), asymmetric operations (RSA up to 4096 bits, ECC on NIST and Brainpool curves, Ed25519), and hashing (SHA-1 through SHA-512), all accelerated by the P71’s dedicated cryptographic co-processor.
For applications where JavaCard bytecode performance is insufficient — for example, real-time cryptographic protocols or custom communication stacks — NXP’s SecureBox framework allows development directly in native C against the JCOP RTOS APIs. This path requires an NXP SecureBox development agreement and hardware security modules for code signing. Our development environment is based on Eclipse with the NXP JCOP Tools plug-in for simulation and debugging, supplemented by a hardware simulation environment using NXP JCOP Shell for on-card testing.
APDU handling, standard crypto operations, GlobalPlatform card management
Custom algorithms, exotic cryptography, FAME3 coprocessor access
ARM SC300 processor, hardware crypto accelerators, EAL6+ certified secure element
When integrating a secure element into a hardware product — whether a dedicated security token, an industrial IoT gateway, or a consumer device — the host microcontroller communicates with the SE over a standardised interface. The most common interface for card-based secure elements is ISO 7816-3 (T=0 or T=1 protocol) for contact interfaces and ISO 14443 for NFC. Embedded secure elements in module form (such as the NXP SE050) additionally support I²C, SPI, and UART, making integration into resource- constrained MCU environments straightforward.
A critical design decision is the choice of communication interface, which involves trade-offs between throughput, convenience, communication window length, and the physical environment. Below are the three primary options to consider when scoping your product integration.
Faster sustained throughput, more reliable in electrically noisy environments, and supports longer communication sessions. Requires physical insertion into a
card reader, making it ideal for security-critical desktop or terminal applications.
Tap-and-go convenience with no physical contact required. Communication windows are shorter due to RF field dependency and power constraints, making
session management more important. Best suited for access control, payment, and mobile use cases.
Combines both contact and NFC on a single card with a single secure element chip, sharing the same applets and data. Provides maximum deployment
flexibility and is the standard form factor for modern payment and identity cards.
Bringing a secure element product from concept to certified production is a structured process that
demands rigorous documentation, independent security evaluation, and careful supply-chain management. Common Criteria certification for a composite product — the combination of a certified SE hardware platform and a custom applet — requires the applicant to produce an evaluation evidence package that covers the security target, the design documentation, and the test results. We guide customers through each stage.
Production deployment involves card personalisation — the process of loading the final applet, injecting root keys, and writing cardholder or device-specific data in a certified personalisation bureau. Key injection is performed under dual-control procedures in a physically secure facility to meet the requirements of the relevant certification scheme and card network rules.
Design
Security target document, assets definition, threat modelling, and security functions specification
Implement
Constant-time crypto, input validation, fault injection defense, and applet firewall configuration.
Test
Functional, security penetration testing, and performance benchmarking against target specifications.
Certify
Common Criteria evaluation evidence packages prepared and submitted to an accredited ITSEF laboratory.
Deploy
Card personalization, key injection, and production deployment in a certified personalisation bureau.
We select the optimal development layer — JavaCard, SecureBox native C, or a hybrid — and deliver a working prototype with benchmarks for your review and approval.
We select the optimal development layer — JavaCard, SecureBox native C, or a hybrid — and deliver a working prototype with benchmarks for your review and approval.
We select the optimal development layer — JavaCard, SecureBox native C, or a hybrid — and deliver a working prototype with benchmarks for your review and approval.
Contact our engineering team to discuss your secure element
development project.
