Your most exposed traffic is being recorded today.
Protect it before its migration.
Many systems cannot move to post-quantum cryptography on your timeline: the application cannot be changed, its TLS cannot be reconfigured, or the vendor is not ready. AvinyaSQ Interim Solutions put post-quantum protection in front of those systems, so their traffic is shielded from harvest-now, decrypt-later attacks today while their full migration follows your transition plan.
No change to the application. Hybrid ML-KEM key exchange on standard TLS 1.3. Policy signed with ML-DSA and controlled centrally.
Migration takes years. Recorded traffic does not wait.
ML-KEM and ML-DSA are standardised, and mainstream TLS libraries support them. The obstacle is deployment. Traffic recorded today can be stored and decrypted once a capable quantum computer exists, so every system waiting for its turn in the migration programme keeps exposing data in the meantime.
Applications that cannot change
Legacy and packaged software whose code or TLS configuration you cannot modify.
Vendors who are not ready
Products that depend on a supplier's post-quantum roadmap, or whose supplier no longer exists.
Data that must stay secret for years
Financial records, health data, industrial telemetry and government communications are exposed now, not when the quantum computer arrives.
Protection at the boundary, in parallel with migration.
Post-quantum protection sits beside your systems, not inside them. It covers exposed traffic now, while the migration programme works through the estate on its planned timeline.
A substitute for migration.
It buys time for the traffic that cannot wait. When a system is migrated natively, its interim protection is retired, connection by connection, with nothing to rip out of the application.
A protected connection
TUNNEL VIEWThree shapes of the problem, three products.
Web traffic, network services shared with others, and connections between systems you own each need a different kind of protection. Each product fits one of them, and all three run from the same platform.
QS-PaaS
A post-quantum proxy for HTTP services.
Terminates post-quantum TLS in front of existing web applications and APIs, and lets classical clients and classical servers communicate with each other using post-quantum or hybrid cryptography. Because it understands HTTP, it can also route traffic and apply policy by path.
PQC protection layers for both clients and server — web portals, APIs and outbound calls from classical clients.
QS-Tunnel Type-1
A post-quantum tunnel for TCP services.
A gateway beside the client and one beside the service carry the traffic over post-quantum, each proving its identity with a post-quantum certificate. It works with peers you do not provision yourself.
Databases, directories, mail and message queues, including links to partners.
QS-Tunnel Type-2
A post-quantum tunnel keyed from the centre.
For connections where both ends are yours. Each pair of gateways uses keys issued by the platform, so keys are rotated and withdrawn centrally, with no certificates on the traffic path. Every connection still adds a fresh post-quantum key exchange.
Traffic inside your estate: between data centres, applications and databases.
Which one fits
The choice is made per connection, so one estate can use all three.
Web or API traffic, where a proxy can take over the TLS in front of the application?
Another TCP service, or a connection where the far end is not yours?
Both ends are yours, and you want keys issued, rotated and withdrawn centrally?
Run all three from one place.
Everything above the traffic path is shared across the three products, so adding a second product does not mean a second system to operate.
One console
Register and approve gateways, deploy policy, and see what each gateway is actually running.
Signed policy
Cryptographic settings reach every gateway as policy signed with ML-DSA, and each gateway verifies it before applying it.
Configured, not coded
Key-exchange algorithms are chosen by policy, so moving to a different algorithm is a configuration change rather than new code.
Built on open standards
TLS 1.3, ML-KEM (FIPS 203) and ML-DSA (FIPS 204). No proprietary protocol to defend in a security review.
What it protects. Interim Solutions protect the confidentiality of data in transit across the network. That is the exposure harvest-now, decrypt-later attacks exploit, and the one that cannot be undone later, which is why it comes first.
Why AvinyaSQ Interim Solutions.
No change to the application
Protection is added beside the system, not inside it. Applications, services and their clients stay as they are.
Works beyond your estate
QS-PaaS and QS-Tunnel Type-1 use the hybrid key exchange that standard TLS peers negotiate, so they work with parties you do not provision.
Keys under central control
Where both ends are yours, QS-Tunnel Type-2 lets you issue, rotate and withdraw keys from the centre, pair by pair.
Time for the transition plan
Cover systems waiting for a later migration wave or for a vendor, so the programme can keep its own order.
Close the exposure while you migrate.
Tell us which systems cannot move yet. We will show how Interim Solutions would protect their traffic and which product fits each connection.
Structured walkthrough on your own list of systems. Nothing installed. No implementation commitment required.