You can't migrate to post-quantum what you can't see.
MCert is Antrapol's continuous crypto inventory and monitoring platform. It runs automated CycloneDX CBOM/SBOM discovery across your whole estate and scores quantum risk and produces signed reports you can hand to a regulator. Your cryptographic estate stays visible all the time and not just on audit day.
CycloneDX CBOM/SBOM · Quantum-risk scoring · Continuous monitoring · Secure regulatory reporting
Standards-based discovery mapped to the frameworks your regulators track
The problem
Most organizations can't plan a PQC migration. They're planning it blind.
RSA and ECC keys · certificates · protocols and crypto libraries sit scattered across servers · applications · network devices · containers and code repositories. Nobody has a single current view of where quantum-vulnerable cryptography actually lives and you can't prioritize a migration you can't measure.
No inventory and no plan
Without knowing which algorithms · certificates · keys and protocols are deployed PQC migration planning is impossible and unknown weaknesses go unaddressed.
Point-in-time audits go stale
Manual discovery is out of date the moment it's collected. Anything that changes between audit cycles gets missed.
Fragmented formats
Each team and tool records inventory its own way so aggregating and comparing and reporting to regulators turns inconsistent and slow.
No quantum-risk lens
You can't judge which assets are quantum-vulnerable until you map discovered crypto to known vulnerability classes and migration priorities.
The inventory is itself a target
A crypto inventory exposes your security posture and its weak points. Without encryption and access control that inventory becomes a prize for attackers.
No safe channel to regulators
Sending posture reports to regulators like NACSA and BNM needs encrypted transfer with verifiable integrity. Ad-hoc methods leak.
The point is simple: you cannot migrate to post-quantum cryptography what you cannot see. MCert keeps the crypto estate visible and standardized and scored against the quantum threat and safe to report.
How it works
Continuous discovery and standardized output and quantum-risk scoring
Lightweight ephemeral scanners run against your assets on a schedule you set. Every result is normalized to CycloneDX and risk-scored and stored encrypted then shown on a live dashboard and packaged into signed reports.
Discover: zero-footprint and ephemeral scanners
Containerized scanners deploy to a target that needs nothing but a container runtime. They find every algorithm · certificate · key · protocol and crypto library then get removed leaving no data behind. A stateless agent is the only thing that touches your infrastructure.
Standardize into CycloneDX CBOM & SBOM
Every scanner's output is normalized into canonical CycloneDX. That ends the format fragmentation and makes your inventory machine-comparable and mergeable across tools and ready for a regulator.
Assess with quantum-risk scoring
The Risk Profile engine tags quantum-vulnerable crypto (RSA · ECC or DH without a PQC hybrid) and deprecated primitives and weak parameters. It computes a risk score per asset and per category then derives a PQC migration-readiness score.
Monitor and report continuously
Scheduled scans keep the inventory fresh and threshold alerts fire when risk climbs. Reports are digitally signed for integrity and non-repudiation and can be encrypted to a recipient for secure transfer to regulators.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"metadata": {
"component": { "name": "payments-api", "type": "application" }
},
"components": [
{
"type": "cryptographic-asset",
"name": "RSA-2048",
"cryptoProperties": {
"assetType": "algorithm",
"algorithmProperties": {
"primitive": "signature",
"parameterSetIdentifier": "2048",
"nistQuantumSecurityLevel": 0
}
}
},
{
"type": "cryptographic-asset",
"name": "ML-KEM-768",
"cryptoProperties": { "assetType": "algorithm" }
}
]
}
Depth of discovery
Cryptography hides in eight places. MCert reaches all of them.
A single server or workstation or network device runs cryptography at every layer of its stack. Most of it is invisible to a network scan or a manual audit. MCert's scanners walk the full stack from the network edge down to the hardware root of trust.
-
1. Network
Certificates and cipher suites negotiated at the edge on every connection in and out.
TLS 1.2 / 1.3 IPsec / IKE VPN tunnels -
2. Application
The crypto libraries linked into the codebase and how the application actually calls them.
OpenSSL / BoringSSL JSSE JWT signing -
3. Remote access
Keys and certificates that authenticate administrators and site-to-site links.
SSH host keys VPN pre-shared keys Client certificates -
4. Database
Encryption protecting data at rest inside the database engine itself.
Transparent Data Encryption Column-level AES TLS to the database -
5. OS / kernel
The crypto modules the operating system depends on for every process above it.
Linux kernel crypto API Windows CNG Disk-encryption drivers -
6. File system & storage
Encryption protecting whole volumes and backups and snapshots at rest.
AES-XTS full-disk Encrypted backups Snapshot encryption -
7. Firmware / BIOS / UEFI
Signature checks that verify the boot chain before the operating system even loads.
Secure Boot UEFI variable signing -
8. Hardware root of trust
The physical anchor every layer above it ultimately chains back to.
HSM key storage TPM-backed keys
Most audits stop at the network edge. MCert doesn't stop until it reaches the hardware root of trust. A migration plan built on a partial inventory is a plan built on a guess.
Quantum-risk scoring
A default risk matrix your experts will recognize
Every discovered component is classified against a transparent default matrix. Subscribers can layer their own risk policies and thresholds on top of the platform defaults.
| Risk class | What MCert flags |
|---|---|
| Quantum-vulnerable | RSA · ECC and DH used without a PQC hybrid. These are the assets to migrate first. |
| Deprecated | MD5 · SHA-1 · DES · 3DES and RC4. Legacy primitives that should already be gone. |
| Weak parameters | RSA below 2048-bit and ECC below 256-bit key sizes. |
| Expiring certificates | Certificates falling inside a configurable expiry threshold. |
| Non-compliant configuration | Protocol versions and cipher suites that don't meet policy. |
| Unknown or unrecognized | Algorithms the scanners can't map to a known classification. |
Risk scores recalculate automatically on every scan and a PQC migration-readiness score tracks the share of components that are PQC-native or protected by a hybrid PQC configuration. Findings map to NIST SP 800-131A · MySEAL · NACSA Directive No. 9 and BNM RMiT. MCert maps to these frameworks. It does not claim certification against them.
What the law now requires
NACSA already requires this. MCert already produces it.
NACSA's Chief Executive Directive No. 9 took effect on 22 September 2025 under the Cyber Security Act 2024. It requires every national critical information infrastructure entity to submit a cryptographic inventory and a risk assessment and a migration plan to NACSA within three months of being notified.
| What Directive No. 9's form asks for | What MCert already produces |
|---|---|
| Jadual 0. Initial inventory | The Discover scan logs every asset with its owner and location and cryptographic function the moment it's found. |
| Jadual 1. Software Bill of Materials | A CycloneDX SBOM generates automatically for every scanned system. |
| Jadual 2. Cryptographic Bill of Materials | The CBOM lists every algorithm and key length and library and flags crypto-agility support exactly as the form asks. |
| Jadual 3. Risk register | The Risk Profile engine scores every asset by risk class and criticality on every scan. |
| Jadual 4. Risk and dependency assessment | Risk scoring and the Crypto Agility Core's dependency view carry impact and likelihood and mitigation straight through. |
| 5-phase migration timeline (Assess · Select · Validate · Deploy · Monitor) | MCert's Migration tracker runs the same five phases with the national template activities and budget lines built in. |
NACSA gives an entity three months from the date of notice to submit this data. Building it by hand from spreadsheets rarely finishes in time. MCert already runs continuously so the workbook becomes an export and not a project.
Source: NACSA Chief Executive Directive No. 9 and its PQC Migration Implementation Form. MCert helps entities prepare the data the Directive asks for. MyPQC is not NACSA and does not submit on an entity's behalf.
Capabilities
What you need to run a crypto-agility observability program
Continuous discovery
Scheduled scans on a cadence you set plus on-demand scans. Covers servers · applications · network devices · container clusters and code repositories.
Zero-dependency scanners
Scanners ship as signed container images. Each one runs in an isolated container with resource limits then gets destroyed. The catalogue also lets you register open-source tools like CycloneDX utilities · Syft · Grype and OWASP Dependency-Check.
CycloneDX normalization
Every result is normalized to canonical CycloneDX whether it started as CBOM or SBOM or SPDX or proprietary. Duplicates are detected and merged across scanners by algorithm and version and location.
Real-time dashboard
Algorithm distribution · a PQC-readiness gauge · certificate-expiry timeline · risk-score trend · scan coverage and mitigation progress. All of it updates as inventory and risk change.
Inventory versioning & diff
Each scan creates a new snapshot per asset. That gives you historical comparison and change tracking and a clear diff of what was added or removed or modified between any two points in time.
Closed-loop remediation
Mitigation plans (say RSA to ML-DSA) tie to live findings. When a later scan shows the component remediated the plan auto-completes with scan evidence. Progress is measured against the real environment.
PQC-native protection
The inventory is encrypted at rest per subscriber with AES-256-GCM. The agent channel and reports are signed with ML-DSA or Malaysia's KAZ-SIGN option with key encapsulation via ML-KEM or Malaysia's KAZ-KEM option.
Secure regulatory reporting
Full-inventory · change · risk · PQC-readiness · compliance and executive reports. Signed for non-repudiation and optionally encrypted to a regulator's key. Output as PDF or JSON (CycloneDX) or CSV or HTML.
Multi-tenant & self-service
Subscriber admins register assets and configure schedules and view inventory and track mitigation within their own tenancy. RBAC roles and strict per-tenant data isolation apply throughout.
Use cases
One platform and three jobs it does immediately
Pre-migration assessment
Set a baseline. Where does quantum-vulnerable RSA/ECC live? Which certificates and keys are weak or expiring? What should you migrate first? Turn a blind migration into a prioritized plan backed by evidence.
Compliance & audit
Produce signed and tamper-evident reports mapped to NIST SP 800-131A · MySEAL · NACSA Directive No. 9 and BNM RMiT and share them with regulators over an encrypted secure-transfer channel. A digitally signed audit trail sits behind every change.
Ongoing drift monitoring
Scheduled scans and snapshot diffs catch new quantum-vulnerable crypto the moment it's introduced and alert on risk-threshold breaches and keep the PQC-readiness picture current. A one-off project becomes a continuous program.
Step 1 of PQC migration
Discover → Govern → Prove
MCert is the observability layer of the MyPQC platform and the first step of any post-quantum migration. You discover your entire crypto estate here. The Crypto Agility Core Engine lets you govern and swap algorithms by policy. MCert's signed reporting lets you prove progress to auditors and regulators over time.
You can't orchestrate a PQC migration or enforce crypto policy on assets you can't see. That's why continuous inventory comes first.
Discover with MCert
Continuous CycloneDX CBOM/SBOM inventory and quantum-risk scoring across the estate.
Govern with the Crypto Agility Core
Change and enforce cryptographic algorithms by policy including the move to NIST PQC standards.
Prove with signed reporting
Signed and regulator-ready reports and a tamper-evident audit trail that measure remediation against the live environment.
Standards & algorithms
CBOM-first and standards-based and honest about assurance tiers
MCert normalizes discovery to CycloneDX and protects its own data and reports with post-quantum cryptography. It pairs NIST-standardized algorithms with optional and policy-selectable national options.
Discovery & exchange formats
- CycloneDX CBOM & SBOM: the canonical bill-of-materials format for cryptographic and software assets supported from CycloneDX 1.4 forward.
- SPDX 2.3+ for SBOM interoperability.
- Report output complies with the CycloneDX CBOM exchange format for machine-readable regulatory submissions.
Protecting the inventory & reports
- Signing with ML-DSA (FIPS 204) with Malaysia's KAZ-SIGN available as an option alongside it.
- Key encapsulation with ML-KEM (FIPS 203) with Malaysia's KAZ-KEM available as an option alongside it.
- Symmetric encryption of inventory and reports with AES-256-GCM using per-subscriber keys.
ML-KEM (FIPS 203) and ML-DSA (FIPS 204) are finalized NIST post-quantum standards. KAZ-SIGN and KAZ-KEM are optional and policy-selectable Malaysian algorithms offered alongside the NIST standards. They are not NIST-standardized or approved. Because algorithm choice is policy-driven that national option can be swapped at any time as standards and threats evolve.
See your entire crypto estate before you migrate
Start with a continuous CycloneDX CBOM/SBOM inventory and quantum-risk baseline for your organization.