Composite Certifications: Smart Cards, Applets, and Platform Stacks

A composite certification is a Common Criteria evaluation that builds on top of a previously certified component. The evaluator does not re-test the lower layer. The lower layer’s certificate is consumed as evidence, and the upper evaluation checks that the new product uses the lower layer correctly. Smart cards, Java Card applets, secure elements, eSIMs, eUICCs, and most SESIP IoT platforms are evaluated this way.

Summary: A composite certification covers an upper-layer product (the composite-product) that depends on an already certified lower layer (the composite-platform). The Composite Evaluation Methodology defines how the upper evaluation reuses the lower certificate’s evidence. The resulting certificate explicitly references the layer beneath as a dependency. It does not re-certify it, and it does not promote the upper layer’s assurance to the lower layer’s EAL.

What “composite” means in Common Criteria

In ordinary Common Criteria (ISO/IEC 15408) language, a Target of Evaluation is a self-contained product evaluated end to end. A composite evaluation breaks that pattern. The new product is layered on top of a component that already holds its own certificate, and the upper evaluator treats that lower certificate as part of the evidence base.

Two terms recur in the Composite Evaluation Methodology, in CC:2022 supporting documents, and in scheme guidance:

Composite-product: the upper-layer Target of Evaluation, the thing being newly certified. An applet, an upper-layer firmware module, a SESIP application running on a certified platform.
Composite-platform: the certified lower layer the composite-product depends on. A Java Card platform under an applet; an integrated circuit under a Java Card platform; a SESIP-certified root of trust under a higher-layer SESIP application.

The composite certificate covers the composite-product as evaluated on the named composite-platform configuration. It does not re-certify the platform, and it does not extend to other platform configurations the upper product was not exercised against.

The classic three-layer smart card stack

The most familiar example is a payment, identity, or travel-document smart card, which is typically evaluated as three independent certifications, each depending on the layer below.

Layer 3   Applet                 (e.g. ePassport, eID, payment)
            |
Layer 2   Java Card platform     (Java Card VM and runtime)
            |
Layer 1   Integrated circuit     (the silicon and its ROM)

Layer 1, the integrated circuit (IC), is typically evaluated against the Security IC Platform Protection Profile family, most often the Security IC Augmented Package v1.0 (BSI-CC-PP-0084-2014, abbreviated SECURITY_IC_AUGP_V1.0). High-assurance ICs sit at EAL5 or EAL6 with AVA_VAN.5 (high attack potential). These are predominantly issued through the German BSI scheme.
Layer 2, the Java Card platform, is a composite-product on top of the IC. Its evaluation reuses the IC certificate; the platform developer documents which IC configuration the platform was exercised on. Platforms in the JCOP family of platform protection profiles are common.
Layer 3, the applet, is a composite-product on top of the platform. The applet evaluator reuses both the platform certificate (directly) and, by transitivity, the IC certificate beneath it.

The applet certificate is what the vendor usually advertises. The platform and IC certificates are the load-bearing dependencies underneath, and they are what fail silently when something goes wrong upstream.

SESIP composition

SESIP (Security Evaluation Standard for IoT Platforms), published by GlobalPlatform, was designed from the start as a composable scheme. SESIP composition follows the same shape as composite Common Criteria: an IoT application is evaluated as a composite-product on top of a SESIP-certified platform, which is itself typically a composite-product on top of a certified root of trust.

The practical difference is that SESIP composition is the default expectation for the corpus, not a special methodology bolted onto a non-composable framework. SESIP certificates therefore tend to surface the platform dependency more visibly in the certificate header, and SESIP allows recognition of an underlying CC certificate as evidence at the platform layer. The composability is the point of the scheme.

How the upper evaluation reuses the lower evidence

The Composite Evaluation Methodology (originally CCDB-2007-09-001, revised in later CCDB releases and aligned with the ISO/IEC 18045 Common Evaluation Methodology, CEM) is the supporting document that tells evaluators how to perform a composite evaluation. The essentials:

The lower-layer (composite-platform) developer prepares composite guidance documenting how to use the certified platform in a higher-layer evaluation: which interfaces, which configurations, which countermeasures the upper layer must respect, and which classes of misuse will invalidate the platform’s assurance.
The lower scheme issues an ETR for composition (Evaluation Technical Report for composition), a redacted slice of the platform’s ETR that the upper evaluator can rely on without seeing the full confidential report. The redaction is what lets the platform vendor protect IP while still feeding the upper evaluation.
The upper-layer evaluator performs all the usual work units (ASE for the Security Target, ATE for testing, AVA for vulnerability analysis) and additionally checks that the composite-product uses the composite-platform within the bounds the platform certificate covered.
The upper certificate’s Security Target identifies the composite-platform certificate by reference. The certification report and the issued certificate name the dependency.

What a composite certificate says, and what it does not

The composite certificate covers the upper layer on the named lower configuration. Read precisely:

It says: this composite-product, in the configuration described in its Security Target, was evaluated to the stated assurance level on top of the named composite-platform certificate.
It does not say: the composite-platform is hereby re-certified. The platform’s certificate stands on its own; the composite evaluation merely consumes it.
It does not say: the upper layer inherits the platform’s EAL. An applet at EAL5+ on a platform at EAL7 on an IC at EAL6+ is still an EAL5+ applet, because that is the assurance package the applet evaluation actually targeted.
It does not say: any other configuration of the platform works. The applet was exercised against a specific platform configuration; running it on a different one is outside the evaluated scope.
It does not say: the chain is still valid next year. Each certificate has its own validity and surveillance schedule.

Procurement-relevant gotchas

Six recurring patterns when a buyer treats a composite certificate as a single-layer attestation. They appear regularly in real procurement files, and they are what the Common Criteria procurement guide flags as the composite-shaped red flag.

Lapsed underlying component certificate. The applet certificate may still be active while the platform or IC certificate has expired, been archived, or moved to surveillance suspended. The composite claim weakens accordingly. Verify each layer’s lifecycle state, not just the headline.
Configuration mismatch between evaluated platform and deployed platform. The applet was evaluated against a specific platform configuration: modules enabled, cryptographic libraries selected, options set, optional features included or excluded. Deploying the applet against a different configuration of the same platform certificate puts the buyer outside the evaluated scope, even when the platform certificate identifier matches on paper.
Multi-vendor stack with split responsibility. Many composites span vendors: an IC from one foundry, a Java Card platform from a second vendor, applets from a third. Surveillance, patching, and end-of-life dates run on three independent timelines. A patch on one layer can require re-evaluation on the others, and the vendor of the headline certificate is rarely positioned to commit on behalf of the layer owners below.
Independent surveillance state on each layer. Each scheme tracks its certificates separately. A composite chain can have one layer in surveillance suspended or undergoing assurance continuity for an impact analysis while the others are active. Read each layer’s status at the issuing scheme, not the aggregate marketing claim. See security target review for buyers for the equivalent buyer-side reading discipline applied to a single ST.
Protection Profile claims at the wrong layer. A composite may carry the Security IC Augmented PP at the IC layer, a JCOP family PP at the platform layer, and an applet-domain PP (SSCD, MRTD, eMRTD, payment, eIDAS QSCD) at the top. Cross-vendor comparison only works if the buyer is comparing certificates from the same layer of the stack. Comparing an applet-layer PP claim against an IC-layer PP claim measures nothing useful.
Augmentations that do not survive the climb. A high AVA_VAN level at the IC layer (AVA_VAN.5) is not transferred to the applet, which may carry AVA_VAN.3 or AVA_VAN.4. The composite is bounded by the upper layer’s vulnerability assessment depth plus what the upper evaluation reused from below. Buyers reading “AVA_VAN.5” on a vendor sheet should ask which layer it applies to.

Verifying a composite chain

A short procurement workflow for tracing a composite stack from the top down. It is not theoretical work; it takes an hour or two per candidate product if the schemes are cooperative, and it is the difference between a defensible procurement decision and a hopeful one.

Open the headline certificate’s Security Target. The Conformance Claims section identifies the composite-platform and lists the platform certificate identifier. Some STs also include a dedicated “composite information” or “composition” section that consolidates the dependency.
Look up the platform certificate identifier at the issuing scheme’s registry. Confirm the certificate is active, in maintenance, or otherwise in good standing. Note the evaluated platform configuration named in the platform Security Target. Treat any vendor-supplied PDF as a starting point, not as the authoritative state.
Repeat the lookup for any layer beneath the platform. If the platform is itself a composite-product on top of an IC certificate, traverse that link as well.
Cross-check related certifications listings. Some schemes publish related-certification links alongside the certificate page, exposing siblings and dependents at a glance. NenkinTracker surfaces this relationship graph on every certificate detail page and tracks the validity of every layer in the chain, so a lapsed component certificate beneath an otherwise active product surfaces immediately.
Compare the evaluated configuration to the deployed configuration. Match SKU, firmware version, hardware revision, and any optional modules from each layer’s Security Target against what the vendor is actually offering. The configuration delta is where most composite mismatches hide.
Confirm surveillance and maintenance status on each layer. A surveillance pause or unprocessed major-release maintenance at any layer is a procurement signal worth a follow-up question, not a footnote.

For the same exercise on a single non-composite issuance, Anatomy of an EUCC Certificate walks through one cert in the same style of close reading.

Where this matters most

Composite evaluation is the norm, not the exception, across the smart card, secure element, eSIM, eUICC, and SESIP IoT corpus. Buyers in identity, payment, travel-document, automotive, telecom (SIM, eSIM, iSIM), and IoT platform procurement should expect to read multi-layer certificate chains for almost every candidate product. Standalone CC certificates are increasingly the minority in these segments.

For high-value sourcing exercises, the buyer-side discipline of pressure-testing each layer of a composite chain at procurement time, not after the first incident, is what an independent advisor adds. Nenkin Technologies AS offers procurement advisory on that basis: buyer-side only, with hands-on experience reading composites across smart cards, secure ICs and SoCs, Java Card applications, SESIP and PSA Certified IoT platforms, EMVCo payment products, eIDAS Qualified Signature Creation Devices, and Trusted Execution Environments.

Frequently asked questions

What is a composite Common Criteria evaluation?

A composite Common Criteria evaluation is one in which the Target of Evaluation builds on an already certified lower layer (a composite-platform), and the evaluator reuses that lower layer's certificate and evidence rather than re-evaluating it. The classic case is a Java Card applet evaluated as a composite-product on a previously certified Java Card platform, which is itself a composite-product on a certified integrated circuit. CC:2022 and ISO/IEC 18045 define how the upper evaluation handles the dependency.

How does a Java Card applet inherit its underlying platform certificate?

It does not inherit it. The applet's evaluator treats the platform certificate as a documented input: the platform's Security Target, its evaluation technical report, and any composite guidance from the platform developer feed the upper evaluator, who checks that the applet uses the platform's interfaces within the bounds the platform certificate covered. The applet certificate carries its own assurance claim (often a lower EAL than the platform) and references the platform certificate as a dependency.

What is a composite TOE?

A composite TOE is the Target of Evaluation in a composite evaluation: the upper-layer product plus the way it sits on the lower layer. The Security Target identifies the composite-product (what is being newly evaluated) and the composite-platform (the certified layer beneath). The certificate covers the upper layer's behaviour on the identified platform configuration. It does not re-certify the platform, and it does not extend to other platform configurations the upper product was not exercised against.

Why do composite certifications matter for procurement?

Most smart card, secure element, eSIM, and SESIP IoT products a buyer evaluates are composites. The headline certificate is the top of a stack, and the assurance claim only holds if every layer below is still in date, configured the same way as the evaluation, and free of unhandled vulnerabilities. Buyers who read only the top certificate miss lapsed underlying components, configuration drift, and multi-vendor stacks with split surveillance and patching obligations.

What is the Composite Evaluation Methodology?

The Composite Evaluation Methodology is a supporting Common Criteria document (originally CCDB-2007-09-001, revised through later CCDB releases and aligned with ISO/IEC 18045) that tells evaluators how to perform a composite evaluation. It specifies the evidence the lower-layer developer must supply to upper-layer evaluators (composite guidance, the ETR for composition), what the upper evaluator must check on top of the normal ASE, ATE, and AVA work units, and how to identify the dependency in the certification report and Security Target.

How do I verify a composite certificate chain at procurement time?

Start at the headline certificate and open its Security Target. The Conformance Claims section (and any composite information section) identifies the composite-platform and its certificate identifier. Look that up at the issuing scheme's registry and confirm the platform certificate is active, its evaluated configuration matches what the upper layer was tested on, and surveillance is current. Repeat for any layer beneath. If any layer is expired, archived, or suspended, the top-layer claim weakens accordingly.