English 
Tiếng ViệtTamper-evident physical protection
Critical components are obscured and covered by black, opaque, tamper-resistant epoxy; penetration or removal is designed to leave visible damage or render the module unusable.
VALIDATED HARDWARE TRUST ANCHOR
Active validationHardware moduleFirmware V1.3.02
Trusted Key Token
FIPS 140-3 Level 3.
A portable hardware cryptographic module recorded by NIST CMVP Certificate #5331 at Overall Level 3, with a public validation boundary, tested module identification and non-proprietary Security Policy.
FIPS module validation and PQC algorithm capability are governed as separate claims.
CMVP#5331Overall Level 3
Certificate#5331
StatusActive
ModuleHardware / MultiChipEmbed
FirmwareV1.3.02
Sunset27 Jan 2031
VALIDATION FACTSHEET
Use the exact public record—not a marketing shorthand.
These facts are mapped to the NIST CMVP certificate and the non-proprietary Security Policy. Product quotations and deployments must preserve the identified model, firmware and approved-mode boundary.
- Certificate
- NIST CMVP #5331
- Standard
- FIPS 140-3
- Status
- Active
- Overall level
- 3
- Module type
- Hardware
- Embodiment
- MultiChipEmbed
- Part number
- Trusted-Key
- Validated firmware
- V1.3.02
- Initial validation
- 16 June 2026
- Sunset date
- 27 January 2031
- Laboratory
- EWA - Canada
- Security Policy
- Version 1.1 - 1 April 2026
HARDWARE CRYPTOGRAPHIC BOUNDARY
Keys and sensitive operations stay inside a defined module boundary.
The module is a multi-chip embedded USB token containing Mobile-ID MIDCOS on an HSC32K2 with PAA integrated circuit. The diagram shows the security relationship rather than implying application compatibility.
HOST ENVIRONMENTBusiness applicationPKI · OTP · FIDO · PIV · OpenPGP use cases
Middleware / PC-SC / USB
FIPS 140-3 CRYPTOGRAPHIC BOUNDARYTrusted Key Token
MIDCOSApproved services and role enforcement
HSC32K2 with PAACryptographic processing and protected storage
SSP controlsGeneration · use · zeroization · self-tests
Plaintext CSPs are not entered, output or stored by the module.
CONTROLLED OUTPUTResult + statusNo intermediate key values
WHAT LEVEL 3 MEANS HERE
Security characteristics grounded in this module's public policy.
Identity-based authentication
Distinct Cryptographic Officer and User roles control access to approved services. Previous authentication is cleared on power cycle.
Approved mode only
The module has one operating mode—the FIPS Approved mode entered after power-up—with a visible status indicator.
Protected SSP lifecycle
SSP generation, access and zeroization are mapped to services. Data output is inhibited during key generation, zeroization, self-tests and error states.
Automatic self-tests
Pre-operational and conditional tests run without operator action; operators can initiate power-up tests by resetting or power cycling the module.
Controlled delivery and end of life
Factory initialization, delivery verification and authenticated termination are defined; termination clears CSPs and disables services.
VALIDATED MODULE IDENTIFICATION
Seven tested hardware models share the validated firmware.
A2 is identified without a button; K9, K40, A4B, K49, K50 and K28 are identified with a button. Deployment must still match the complete NIST and Security Policy record.
| Model / part number | Hardware | Firmware | Processor | Form |
|---|---|---|---|---|
| A2 | V1.2 | V1.3.02 | HSC32K2 with PAA | Without button |
| K9 | V1.0 | V1.3.02 | HSC32K2 with PAA | With button |
| K40 | V1.0 | V1.3.02 | HSC32K2 with PAA | With button |
| A4B | V1.0 | V1.3.02 | HSC32K2 with PAA | With button |
| K49 | V1.0 | V1.3.02 | HSC32K2 with PAA | With button |
| K50 | V1.0 | V1.3.02 | HSC32K2 with PAA | With button |
| K28 | V1.0 | V1.3.02 | HSC32K2 with PAA | With button |
SECURITY-LEVEL MATRIX
Overall Level 3 with explicit N/A areas.
Level 3 applies to the listed applicable sections. Operational Environment, Non-Invasive Security and Mitigation of Other Attacks are marked N/A in the certificate and Security Policy.
| FIPS 140-3 area | Level |
|---|---|
| General | 3 |
| Cryptographic Module Specification | 3 |
| Cryptographic Module Interfaces | 3 |
| Roles, Services and Authentication | 3 |
| Software/Firmware Security | 3 |
| Operational Environment | N/A |
| Physical Security | 3 |
| Non-Invasive Security | N/A |
| Sensitive Security Parameter Management | 3 |
| Self-Tests | 3 |
| Life-Cycle Assurance | 3 |
| Mitigation of Other Attacks | N/A |
APPROVED SERVICE FAMILIES
Classical approved services are listed separately from PQC capability.
The public Security Policy includes approved service families such as AES, ECDSA, RSA, SHA-2/SHA-3, HMAC, key agreement, KDF and DRBG. Exact algorithms, curves, modes, key sizes and CAVP references must be read from the current policy.
AESECDSARSASHA-2SHA-3HMACKASKDFCTR_DRBG
Certificate #5331 is not presented as validation of ML-KEM, ML-DSA or SLH-DSA.
PQC provider, firmware, parameter-set and algorithm-validation status must be disclosed through a separate capability and evidence record.
View the PQC capability matrix →OFFICIAL CAVEAT & PROCUREMENT USE
Preserve the full validation boundary in purchasing and deployment.
The NIST record states that generated SSP strength is affected by available entropy and provides no assurance of minimum security for externally loaded SSPs or SSPs established with externally loaded SSPs.
- Verify the certificate status at the NIST source on publication and purchase dates.
- Match model, hardware version, firmware V1.3.02 and approved mode.
- Obtain middleware and application interoperability evidence.
- Keep FIPS module validation distinct from PQC algorithm claims.
NEXT STEP
Evaluate the validated boundary in your target application.
Confirm the exact token model, middleware, operating system, application version, key policy and acceptance evidence before production rollout.