ArcQubit builds QuTrust, a Full Stack post-quantum migration platform for financial institutions, on Microsoft Azure and AWS

QuTrust turns fragmented cryptographic inventories into one living post-quantum migration program for globally supervised financial institutions.

Tampa, Florida. August 1, 2026.


Executive summary

Financial institutions own more cryptography than they can account for, and they are being asked by supervisors in several jurisdictions to prove they can move it. QuTrust gives them one place to plan, run, and evidence that migration.

ArcQubit built QuTrust on Microsoft Azure and Amazon Web Services because the platform's buyers are globally supervised institutions that will not accept anything less than enterprise-grade, and because both providers hold themselves to a security engineering discipline that matches how ArcQubit builds.

QuTrust is in market now, sold through a scoped engagement, with deployment ranging from hosted, to in-perimeter, to sovereign with air-gap capability.


The challenge

Even with mature security programs and significant tooling investment, financial institutions cannot answer a simple board question: where are we in our post-quantum migration, and when will we be finished.

The reason is structural. A global bank runs scanners, certificate managers, cloud posture tools, identity systems, OT visibility platforms, and model registries. Each one produces a true and partial answer. None of them produces the whole picture, and none of them produces a program. Meanwhile the supervisory clocks are not synchronized. An institution answering to the EU Digital Operational Resilience Act, the G7 Cyber Expert Group, the UK National Cyber Security Centre, and the Monetary Authority of Singapore is being asked similar questions on different timelines, in different formats.

Microsoft named this same gap in its own customer guidance. In the July 2026 Secure Future Initiative progress report, the recommended starting actions for any organization include inventorying cryptographic dependencies and establishing transition plans for post-quantum readiness [1]. That is a clear instruction. What it does not come with is the operational layer that turns an inventory into a migration program with owners, sequence, and dates.

That layer is what ArcQubit built.


The integrated solution

QuTrust is an analyzer, not a scanner. It ingests from the tools an institution already runs, then analyzes their collective output into one unified cryptographic posture across four surfaces, always in the same order: Cloud, IT, OT, and AI.

The platform produces two outputs.

The Quantum Exposure Report. A live cryptographic inventory that answers, in real time, what the institution's current post-quantum posture is across every asset it owns, organized so remediation can be sequenced rather than guessed.

The living PQC migration roadmap dashboard. A continuously updated migration program, not a point-in-time assessment, showing what has moved, what is in flight, what is blocked, and what the institution can evidence to a supervisor today.

Three continuous loops run underneath: continuous analysis, continuous prioritization, and continuous reporting. Alignment includes NIST FIPS 203, 204, and 205 [2], NIST SP 800-208 [3], and CISA's Automated Cryptography Discovery and Inventory framework [4].

The scanners are essential. They produce the raw data. QuTrust is where the scanner outputs come to become a migration program.


Why we build on enterprise grade systems

ArcQubit's buyers are systemically important institutions. They send vendor risk questionnaires before they send purchase orders. They ask where data resides, how identity is enforced, how the software is signed, and what happens when the algorithm underneath changes. A platform that cannot answer those questions in its own architecture has no business telling a bank how to answer them.

So our platform choices are not cost decisions. They are alignment decisions. We build QuTrust on Microsoft Azure and Amazon Web Services because both providers hold themselves to the engineering standard our buyers are audited against, and because both have said in public, in their own words, exactly where their responsibility ends and the institution's begins.

What Microsoft's engineering discipline gives us

Secure by design is a build discipline, not a marketing line

Microsoft's Secure Future Initiative runs on three principles, secure by design, secure by default, and secure in operations, applied through six engineering pillars and governed by Zero Trust principles from the engineering core outward [5]. Microsoft frames security not as a milestone or a point-in-time investment but as a continuous discipline that is designed in, enabled by default, and continuously revalidated as the threat landscape changes [6].

ArcQubit builds QuTrust the same way, and for the same reason. QuTrust's four-tier deployment ladder, hosted to in-perimeter to sovereign with local self-run tooling and air-gap capability, is a Zero Trust posture expressed as a commercial option. An institution under data residency and cross-border restrictions does not get a compromised version of the product. It gets the same analysis, inside its own boundary.

Crypto-agility is the engineering standard, and it is the standard we hold ourselves to

Microsoft's published position on crypto-agility is precise: remove hard-coded algorithm assumptions, persist enough information to reconstruct cryptographic context, and build systems so that algorithm upgrades become routine engineering work rather than emergency rewrites, using self-describing cryptographic metadata or versioned ciphertext formats so implementations can read legacy data while writing with current approved algorithms [7].

That definition maps almost line for line onto QuTrust's unified crypto-observation model. QuTrust records cryptographic context in a self-describing form precisely so that an institution can answer questions about its own past decisions years later, which is the thing that makes a migration auditable rather than merely completed. We adopted this vocabulary deliberately. It means any cloud architect on the other side of the table understands what QuTrust does on the first call, without translation.

The migration is already in production, so the roadmap has to survive contact with it

This is not a forecast anymore. Post-quantum algorithms became generally available in Windows Server 2025, Windows 11, and .NET 10 [8]. In May 2026, Active Directory Certificate Services support for issuing ML-DSA certificates on Windows Server 2025 reached general availability, across the ML-DSA-44, 65, and 87 parameter sets, bringing quantum-resistant signing into enterprise public key infrastructure for certification authorities and OCSP responders [9].

Our customers now have real post-quantum PKI running in production environments. That is exactly the moment when a migration roadmap stops being a slide and starts being a delivery program with named owners, budget lines, and quarterly reporting.

What the AWS migration plan gives us

Most institutions we work with are not on one cloud. A global bank runs Azure in one business line, AWS in another, and something inherited in a third. A migration platform that only understands one provider is not a migration platform. It is a reporting tool with a blind spot.

AWS matters here for a second reason. It has published one of the most operationally specific post-quantum positions of any provider, and that specificity is what makes a roadmap enforceable.

The shared responsibility model draws the line we build against

AWS delivers post-quantum capability under its shared responsibility model, where some features are transparently enabled for every customer and others are options the customer must choose in order to meet their own requirements [10]. AWS is explicit that customers must update their TLS clients and SDKs to offer ML-KEM when connecting to service endpoints, while the endpoints are responsible for selecting it when offered [11].

That line is the entire reason QuTrust exists. Both major providers will migrate their side. Neither will migrate yours, and neither will tell your board which side of the line each of your ten thousand cryptographic dependencies falls on. Answering that question, continuously, across every environment an institution owns, is the work.

Cryptographic telemetry is the named deliverable, and it is what QuTrust produces

AWS guidance for security leaders is unusually direct about method. Rather than attempting to inventory everything, it advises classifying dependencies into three categories: what providers will upgrade on your behalf, what they will not upgrade in time and therefore needs replacing, and what you own and must address directly. The fastest way to shrink migration scope is to move as much as possible into the first category. Alongside that, AWS advises investing in cryptographic telemetry, building visibility and monitoring in parallel with migration work rather than sequentially, and warns that organizations that defer will inherit compressed timelines, higher costs, and less optionality [12].

Read that as a product specification and you have described QuTrust. The Quantum Exposure Report is cryptographic telemetry. The living migration roadmap is the three-way dependency classification, maintained continuously rather than rebuilt each quarter, with the provider-upgrade column shrinking the institution's own scope as Azure and AWS ship.

AWS also frames crypto-agility as an operational capability rather than a project: the ability to rotate algorithms, update protocols, and absorb cryptographic change as business as usual instead of as a dedicated program, on the reasoning that standards will keep evolving and algorithms will keep being deprecated and replaced. That is the same conclusion Microsoft reaches from a different direction, and it is the assumption QuTrust is built on.

The generational replacement already happened once

AWS is worth studying because it has already run the experiment. It began shipping hybrid post-quantum key exchange years before the standards existed, cycling through a full generation of pre-standard algorithms that were later replaced. In April 2026, ML-KEM hybrid post-quantum TLS became active by default across KMS, ACM, Secrets Manager, Payment Cryptography, and S3 public endpoints, while support for CRYSTALS-Kyber, ML-KEM's pre-standardization predecessor, is being removed across AWS endpoints during 2026 [13]. Underneath sits AWS-LC, the FIPS 140-3 validated cryptographic library that AWS describes as the first open-source cryptographic module to include ML-KEM in its FIPS validation, with services including KMS and Private CA supporting quantum-resistant signatures and roots of trust through ML-DSA [14].

The lesson in that history is not about any one algorithm. Systems that could absorb the change by updating a library and a policy setting migrated cheaply. Systems that hard-coded a cipher suite list, pinned an algorithm identifier, or embedded a public key in firmware did not. An institution that cannot tell those two categories apart across its own estate cannot forecast its migration cost, and that is precisely the distinction QuTrust surfaces.

Financial services already has its own framework, and we map to it

For our buyers specifically, AWS points to the Accredited Standards Committee X9, the ANSI-accredited body that writes standards for financial services, which published a Post-Quantum Cryptography Financial Readiness Needs Assessment covering cryptographic asset inventory, risk-based prioritization, PQC migration planning, and building crypto-agility into financial infrastructure [10]. AWS also references the CISA strategy for migrating to automated post-quantum cryptography discovery and inventory tools, the same framework QuTrust aligns to.

Those four X9 activities are the four things QuTrust does. We did not build toward that framework by accident. We built toward it because our buyers will be measured against it.

The gap both providers name

Read Microsoft's Secure Future Initiative guidance and the AWS migration plan side by side and they converge on one instruction: build a cryptographic inventory, classify what you depend on, and make algorithm change routine. Neither provider claims to do that for you. Both are explicit that it sits on your side of the line.

That is the gap. QuTrust is the platform that closes it, on both clouds, across Cloud, IT, OT, and AI, and it produces the evidence a supervisor will accept.


Where the market moved

On June 30, 2026, Microsoft committed to transitioning its critical products and services to post-quantum cryptography by 2029, roughly four years ahead of the completion date it had published ten months earlier, and folded post-quantum requirements into the Secure Future Initiative itself. Azure Chief Technology Officer Mark Russinovich attributed the acceleration to a shifted risk horizon, noting that cryptographically relevant quantum computers may arrive sooner than previously expected and that the preparation work is substantial. [15]

For a financial institution, that date is a lever. A public vendor completion commitment is the kind of date that belongs in a renewal negotiation, alongside FIPS 140-3 validation status and crypto-agility commitments. But writing the date into a contract only matters if the institution can verify it, track it across every vendor it depends on, and prove the state of its own estate at the same time.

That verification is QuTrust's job.

Critical financial systems are expected to migrate between 2030 and 2032, with full transition landing in the mid-2030s. Long-lived financial data is the asset class most exposed to harvest-now, decrypt-later collection, which makes the effective deadline for many institutions earlier than the published one.


Working with Microsoft for Startups

ArcQubit participates in Microsoft for Startups at the Investor Network tier, which provided $100,000 in Azure credits on a non-dilutive basis. The Investor Network path requires a referral code from an investor, accelerator, or incubator within Microsoft's partner network.

The credits shortened the runway to a production-grade environment. We are grateful to the stakeholders and early supporters who backed this work before there was a product to point at, including the investors, advisors, and design partners who gave us their time and their hard questions.


About ArcQubit

ArcQubit's work on quantum technology risk was published and presented at IEEE before QuTrust existed. Our founding team comes out of national laboratories, defense and international nuclear cybersecurity, with more than twenty publications across IEEE, ANS and IAEA forums.

We are not repackaging someone else's scanner. We built the framework this category is measured against.

Learn more. Institutions can request a scoped QuTrust assessment at https://bookings.cloud.microsoft/book/QuTrustBookingPage@arcqubit.ai/


References

[1] Microsoft, "Securing our future: July 2026 progress report on Microsoft's Secure Future Initiative," Microsoft Security Blog, Jul. 10, 2026. [Online]. Available: https://www.microsoft.com/en-us/security/blog/2026/07/10/securing-our-future-july-2026-progress-report-on-microsofts-secure-future-initiative/

[2] National Institute of Standards and Technology, "Post-Quantum Cryptography FIPS Approved: FIPS 203, FIPS 204, and FIPS 205," Computer Security Resource Center, Aug. 13, 2024. [Online]. Available: https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved

[3] D. A. Cooper, D. C. Apon, Q. H. Dang, M. S. Davidson, M. J. Dworkin, and C. A. Miller, "Recommendation for stateful hash-based signature schemes," National Institute of Standards and Technology, Gaithersburg, MD, USA, NIST SP 800-208, Oct. 2020. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf

[4] Cybersecurity and Infrastructure Security Agency, "Strategy for migrating to automated post-quantum cryptography discovery and inventory tools," CISA, Washington, DC, USA, Sep. 2024. [Online]. Available: https://www.cisa.gov/resources-tools/resources/strategy-migrating-automated-post-quantum-cryptography-discovery-and-inventory-tools

[5] Microsoft, "Secure Future Initiative overview," Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/security/zero-trust/sfi/secure-future-initiative-overview

[6] Microsoft, "Secure Future Initiative progress report, July 2026," Microsoft Trust Center, Jul. 2026. [Online]. Available: https://www.microsoft.com/en-us/trust-center/security/secure-future-initiative/sfi-progress-report-july-2026

[7] Microsoft, "Post-quantum cryptography and crypto-agility," Microsoft Tech Community, Post-Quantum Cryptography Blog. [Online]. Available: https://techcommunity.microsoft.com/blog/post-quantum-crypto-tech-blog/post-quantum-cryptography-and-crypto-agility/4530365

[8] Microsoft, "Post-quantum cryptography APIs now generally available on Microsoft platforms," Microsoft Tech Community, Microsoft Security Blog, Nov. 2025. [Online]. Available: https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-apis-now-generally-available-on-microsoft-platforms/4469093

[9] Microsoft, "New Windows features to secure today's data in a post-quantum world," Microsoft Tech Community, Microsoft Security Blog, May 2026. [Online]. Available: https://techcommunity.microsoft.com/blog/microsoft-security-blog/new-windows-features-to-secure-today%E2%80%99s-data-in-a-post-quantum-world/4523370

[10] Amazon Web Services, "Migration to post-quantum cryptography," AWS Security. [Online]. Available: https://aws.amazon.com/security/post-quantum-cryptography/migrating-to-post-quantum-cryptography/

[11] Amazon Web Services, "ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager," AWS Security Blog. [Online]. Available: https://aws.amazon.com/blogs/security/ml-kem-post-quantum-tls-now-supported-in-aws-kms-acm-and-secrets-manager

[12] Amazon Web Services, "The CISO's guide to post-quantum mandates and migrations," AWS Security Blog. [Online]. Available: https://aws.amazon.com/blogs/security/the-cisos-guide-to-post-quantum-mandates-and-migrations/

[13] Amazon Web Services, "Protecting your secrets from tomorrow's quantum risks," AWS Security Blog, Jun. 12, 2026. [Online]. Available: https://aws.amazon.com/blogs/security/protecting-your-secrets-from-tomorrows-quantum-risks/

[14] Amazon Web Services, "Post-quantum cryptography," AWS Security. [Online]. Available: https://aws.amazon.com/security/post-quantum-cryptography/

[15] M. Russinovich, "Accelerating Microsoft's post-quantum cryptography transition," Microsoft, Jun. 30, 2026. [URL TO BE CONFIRMED: link the canonical Microsoft or Azure blog post before publication.]

Your next step

Make the migration measurable.

Start with a working session built around your institution's environment.

Book a working session