Security

TEE vs Secure Element

<\/script>\n
'; }, get iframeSnippet() { const domain = '{ SITE_DOMAIN }'; const type = '{ embed_type }'; const slug = '{ embed_slug }'; return ''; }, get activeSnippet() { return this.method === 'script' ? this.scriptSnippet : this.iframeSnippet; }, copySnippet() { navigator.clipboard.writeText(this.activeSnippet).then(() => { this.copied = true; setTimeout(() => { this.copied = false; }, 2000); }); } }" @keydown.escape.window="open = false" @click.outside="open = false">

Embed This Widget

Theme


      
    


    
    

      Widget powered by
      .
      Free, no account required.
    

  




  
  
Comparing TEE and Secure Element architectures for mobile and IoT security: isolation models, certifiability, and use case fit.

  
  

    
    
    |
    4 min read
    
  








  
  

    
    
      
      
  1. 
        TEE vs Secure Element
      
    2. 
      
      
  2. 
        Definitions
      
    3. 
      
      
  3. 
        Security Property Comparison
      
    4. 
      
      
  4. 
        Attack Surface Analysis
      
    5. 
      
      
  5. 
        Use Case Matrix
      
    6. 
      
      
  6. 
        GlobalPlatform and TEE API
      
    7. 
      
      
  7. 
        Hybrid Architectures
      
    8. 
      
    

  









  
  

  
  

    
    

      
TEE vs Secure Element


Trusted Execution Environment (TEE) and Secure Element
(SE) are both hardware-backed security boundaries, but they differ fundamentally in
their threat model, certification depth, and application model. Choosing between them
— or combining them — is one of the most consequential decisions in mobile and
embedded security architecture.


Definitions


Trusted Execution Environment (TEE): An isolated execution environment on the
application processor, implemented via ARM TrustZone (or RISC-V equivalent). Code
running in the Secure World (TEE) is logically isolated from the Normal World (OS),
but shares the same physical silicon as the Rich OS.


Secure Element (SE): A separate, dedicated security chip (or die partition in an
SIM integrated into device SoC." data-category="Application">iSIM SoC) with its own CPU, RAM, and non-volatile storage. The SE has its own power
rails and communication buses; it cannot be accessed by the application processor
except via a controlled API.


Security Property Comparison






Property
TEE
Secure Element






Physical isolation
No — shares SoC
Yes — discrete die




Side-channel resistance
Limited — shared cache, power
High — dedicated hardware countermeasures




Fault injection resistance
Low–Medium
High (glitch detectors, shields)




Common Criteria certification
EAL2 typical, EAL4 possible
EAL4+, EAL5+ for high-value SEs




Key storage
Secure World RAM / fused key
Dedicated EEPROM / flash




Attestation
Device Attestation (Android), Secure Enclave (iOS)
Manufacturer + GlobalPlatform




Replacement / provisioning
OTA firmware update
OTA profile management




Cost
$0 (SoC feature)
$2–$8 (discrete chip)






Attack Surface Analysis


TEE Attacks:
- Cache-timing attacks (Spectre-class) can leak TrustZone state on shared L1/L2 caches
- Rowhammer against Secure World memory if DRAM ECC is absent
- Malicious Normal World hypervisor downgrading TrustZone permissions
- Bootloader compromise before TEE initialisation


SE Attacks:
- Side-channel analysis (SPA/DPA) against power traces —
  mitigated by dedicated countermeasures; see SPA/DPA guide
- Physical probing of bus between host SoC and SE (mitigated by AES-based secure channel protocol." data-category="Software">SCP03 encryption)
- Fault injection (laser, EM, voltage glitch) — countered by mesh shields and
  glitch detectors in EAL5+ SEs


Use Case Matrix






Use Case
TEE Sufficient?
SE Required?
Rationale






DRM / media keys
Yes
No
Content protection, not payment




Mobile payment (EMV)
No
Yes
PCI-DSS, EMVCo mandate SE or TEE+SE




FIDO2 platform authenticator
Yes (Level 1)
For Level 2
FIDO L2 requires SE or certified TEE




ePassport chip
N/A — standalone card
Yes
ICAO Doc 9303 mandates dedicated chip




IoT device identity
TEE on capable SoC
Discrete SE for ultra-constrained
Depends on threat model




SIM / eSIM
N/A
Yes — eUICC
GSMA SESP, separate die




Enterprise PIV
No
Yes
NIST SP 800-73, FIPS 201






GlobalPlatform and TEE API


GlobalPlatform defines APIs for both environments:


    

  • GlobalPlatform TEE Client API: Rich World application calls into Trusted
  Application (TA) running in TEE Secure World
    • 

  • GlobalPlatform TEE Internal Core API: APIs available inside a TA (crypto,
  storage, time)
    • 

  • GlobalPlatform Card Spec: APIs for applets running on an SE
    • 



The GP TEE API uses UUIDs to identify Trusted Applications — analogous to
AID on smart cards.


Hybrid Architectures


High-security mobile deployments combine both:


Mobile SoC
├── Normal World (Android / iOS)
│   └── Application (e.g., mobile banking app)
├── Secure World (TEE / TrustZone)
│   └── Trusted App: UI confirmation, secure display path
└── SE (NFC controller + discrete SE)
    └── Payment applet (EMV, transit)
        — Private keys physically isolated from SoC



The TEE handles UI-layer security (secure keyboard input, trusted display) while
the SE holds payment credentials. FIDO2 roaming authenticators use a similar split:
TEE for user verification (biometric), SE for credential storage and signing.


For the hardware backing these security boundaries, see
Smart Card Lifecycle Security and
HSM Integration.

    

    

    
    
    
    

    
    

      




  
Frequently Asked Questions


  

    
    

      
      

        
Our guides cover a range of experience levels. Getting Started guides introduce smart card fundamentals. Security guides address Common Criteria certification and key management. Programming guides target developers working with APDU commands, JavaCard applets, and GlobalPlatform card management.