Dubai’s Cyber Chiefs Closed GISEC on 18 September With a Post-Quantum Deadline — I Audited 6 of Our Codebases for Hard-Coded RSA, 4 Failed, and Here Are the 5 Questions I Now Ask Every Backend Engineer

I spent the last afternoon of GISEC Global 2026 in the Quantum Security Summit, and I came back to the office with a problem I had been politely ignoring for two years. The 15th edition of the Middle East and Africa’s largest cybersecurity event closed on Thursday 18 September at Dubai Exhibition Centre with more than 25,000 attendees, 750-plus exhibiting brands and speakers from over 180 countries, and its final day was not about the threats of this quarter. It was about the one that arrives on a date nobody knows and that every serious government in the room is now planning for anyway. On Friday morning I pulled up the six production codebases we maintain for Dubai clients and asked one question of each: if the signing algorithm had to change next month, how many files would we touch? Four of the six failed. This article is what I learned, and what I have changed in the way we interview backend engineers because of it.

What Was Actually Said on the Final Day of GISEC

The closing day was organised around a dedicated Quantum Security Summit. According to the organiser’s closing release, the sessions moved the conversation “from the future potential of quantum computing towards the practical challenge of preparing today’s digital infrastructure for post-quantum security”. Three things in that programme matter to anyone who employs developers in the UAE.

• Dr Bushra Al Blooshi, Executive Director of Cybersecurity Governance and Risk Management at the Dubai Electronic Security Center (DESC), examined how nations are developing post-quantum cryptography (PQC) roadmaps and migration timelines. DESC is the body that writes Dubai’s information security standards for government entities and their suppliers. When its governance lead talks about migration timelines on a public stage, the supplier questionnaires follow.
• Dr Saeed Aldhaheri, Chairman of the Robotics and Automation Society, presented a proposed roadmap for protecting UAE data and critical digital infrastructure ahead of “Q-Day”, and said: “Quantum computing is bringing the need for post-quantum readiness into sharper focus. The UAE must begin migrating to quantum-safe cryptography now, strengthening crypto agility, national capabilities and talent to protect sensitive data before quantum threats become a practical reality.” Note the three nouns at the end. Crypto agility, capabilities, talent. That is a hiring sentence.
• Experts from TII (Abu Dhabi’s Technology Innovation Institute), ENEC (the nuclear operator) and CPX (the Abu Dhabi cybersecurity firm) discussed practical migration challenges across critical entities, with contributions from IBM and Google Cloud on enterprise migration and post-quantum readiness.

Two other final-day sessions frame the hiring problem from opposite ends. On the Dark Stage, in a session titled Too Young to Hack? Think Again, two teenage security researchers from India, Bandana Kaur and Ryen Agil, walked through vulnerabilities they had found at the very start of their careers. And Prashant Haldankar, Group CISO of the Australian firm Sekuro, put the operational reality in one sentence: “Attackers are already moving at machine speed, and that’s reshaping how we think about defence.” The event opened on Tuesday with DESC’s SARAAB deepfake detector, which we covered in our note on identity checks for remote developer interviews; it closed with a cryptographic deadline. Both are your problem now.

Post-Quantum, in the Terms a Dubai Employer Needs

You do not need to understand quantum computing to understand the business risk, so here is the whole thing in four sentences. The public-key algorithms that secure almost every login, payment, API call and software update today (RSA and elliptic-curve cryptography) are safe against every computer that exists. A sufficiently large quantum computer would break them, and while nobody can say when one will exist, adversaries can record encrypted traffic today and decrypt it later, which is why data with a long shelf life (medical records, land registries, national ID, contracts) is already exposed. The replacement algorithms have existed since August 2024, when NIST published FIPS 203 (ML-KEM, for key exchange), FIPS 204 (ML-DSA, for signatures) and FIPS 205 (SLH-DSA). And the timeline is written down: NIST IR 8547 deprecates the common 112-bit algorithms (RSA-2048, ECDSA P-256) by 2030 and disallows all quantum-vulnerable public-key cryptography by 2035.

The UAE has not set a single national date, and DESC did not announce one on Thursday. What GISEC made clear is that Dubai’s regulators are building roadmaps by sector, starting with government, energy and finance, and that the migration is being treated as a project with a start date rather than a research topic. If you sell software or run systems for any of those sectors, the first practical consequence is a questionnaire: where is cryptography used in your product, which algorithms, and what is your migration plan? The companies that cannot answer the first part will not get to the third.

Here is the thing most of the executive summaries miss. Swapping an algorithm is easy. Finding every place your systems chose an algorithm is the actual work, and whether that work takes three weeks or nine months depends entirely on how your engineers built the system in the first place. That property has a name, and Dr Aldhaheri used it on stage: crypto agility.

The Audit: 6 Dubai Codebases, 1 Question, 4 Failures

The test was deliberately simple. For each codebase, I asked: if we had to replace the primary signing or key-exchange algorithm with an ML-DSA or ML-KEM equivalent, could we do it as a configuration change plus a library upgrade, or would it require touching application code in more than five places? Five is arbitrary but useful; above it, the change needs a project plan, testing across every consumer, and a coordinated rollout, which in Dubai means a change-advisory board and, for regulated clients, a notification.

None of the four failures is insecure today. That is precisely why they were ignored. Each one was built by competent engineers who made a reasonable choice in 2020 or 2021 and wrote the choice into the code rather than into configuration, because nobody asked them to do otherwise. The IoT gateway is the worst case: devices in the field with certificates valid until the mid-2030s, past the NIST disallow date, on hardware whose firmware update path is itself signed with the algorithm that needs to change. That is not a sprint. That is a two-year programme with a hardware refresh in it, and the budget conversation with the client starts next week.

The 5 Questions I Now Ask Every Backend Engineer Candidate

I rewrote our backend interview loop over the weekend. These five questions take about twenty-five minutes in the technical round. They are not trick questions and I tell candidates in advance that the topic is coming. What I am scoring is not whether they have heard of post-quantum cryptography; it is whether they instinctively think about cryptography as a swappable dependency or as a fact of nature.

1. “In the last system you built, where was the signing algorithm decided, and how many places would you change to swap it?”

This is the whole audit in one question. A strong answer names a specific place (a key-management module, a KMS parameter, an identity provider configuration) and a number under five. A weak answer is “we used RS256 for the JWTs” with no idea where that string lives. An honest “everywhere, and I would not do it that way again” scores higher than a confident wrong answer; I am hiring the reflex, not the record.

2. “What is the difference between ML-KEM and ML-DSA, and where does each go in a web stack?”

Key encapsulation (ML-KEM, FIPS 203) replaces the Diffie-Hellman exchange in TLS and anywhere two parties agree a session key; digital signatures (ML-DSA, FIPS 204) replace RSA and ECDSA in tokens, certificates, code signing and webhook verification. A candidate who can place the two correctly can plan a migration. One who says “they are both quantum-safe” can only follow one. I do not expect parameter sets or key sizes from memory, though a mention that ML-DSA signatures are several kilobytes and will bloat a JWT is a very good sign.

3. “How would you build a cryptographic inventory of a service you did not write?”

The answer I want has three layers: static (grep the codebase and dependency tree for algorithm identifiers, library calls and key-loading code), runtime (what the TLS terminator, the JWT library and the KMS actually negotiate, read from logs or a proxy), and artefacts (certificates, their validity periods, and where they are stored). Bonus points for the phrase “cryptographic bill of materials” or for asking whether the client already has a software bill of materials to start from. Engineers who have done one dependency audit for a CVE, the kind we described after the vCenter zero-day in August, usually answer this well; the method is the same.

4. “Your TLS terminator now negotiates a hybrid key exchange. What changes in your application, and what could break?”

Hybrid key exchange (a classical curve combined with ML-KEM) is already the default in mainstream browsers and at the large CDNs, so most Dubai companies are running post-quantum TLS at the edge without having decided to. The right answer is “nothing in the application, if TLS is properly delegated”, followed by the things that break in practice: middleboxes and older load balancers that choke on the larger ClientHello, certificate-pinned mobile apps, and internal services that terminate their own TLS with a pinned library version. A candidate who knows that the pinned mobile app is where the pain lives has been through a migration before.

5. “A signing key lives in an HSM as RSA-4096. The vendor says post-quantum firmware is 18 months out. What do you do this quarter?”

There is no clean answer, which is the point. Good responses talk about reducing the blast radius now (shorten certificate lifetimes, rotate more often, put an abstraction in front of the HSM so the swap is one change later), about dual-signing during transition, and about writing the vendor timeline into the risk register so it is a management decision rather than an engineering secret. Bad responses either wait for the vendor or propose replacing the HSM next week without asking who signs the change. The question tests judgement under a constraint that actually exists in every Dubai bank and utility right now.

What to Change in Your Next Backend Requisition in Dubai

Three lines. That is all it takes, and none of them says “quantum”.

1. Under responsibilities: “Own the cryptographic inventory for the services you build; keep algorithm selection in configuration and key material in the managed KMS.” This tells the right candidates that you know what you are asking for, and it tells the wrong ones to keep scrolling.
2. Under requirements: “Experience with at least one TLS, certificate or key-management migration in production.” Not “knowledge of post-quantum cryptography”. You want somebody who has felt a migration break a mobile app at 2 a.m., not somebody who has read about lattices.
3. Under nice-to-have: “Familiarity with FIPS 203/204 and hybrid TLS key exchange.” This is where the genuinely current engineers will recognise themselves, and it costs you nothing to ask.

On compensation, in our placements this year the engineers who answered the five questions credibly have sat 10 to 20 percent above the standard senior backend band in Dubai, which currently runs roughly AED 25,000 to AED 40,000 a month depending on stack and sector. That is a smaller premium than for AI specialists. The skill is rare rather than expensive, because the people who have it are usually not marketing it. Our guide to hiring cloud security engineers in Dubai covers the adjacent profile if you are building a dedicated team rather than adding the skill to an existing one; the UAE cybersecurity law explainer is the regulatory backdrop your legal team will ask about.

The Two Teenagers on the Dark Stage, and the Line I Deleted From Our Job Ads

The most uncomfortable session of the day was not the quantum one. Too Young to Hack? Think Again put two teenage security researchers, Bandana Kaur and Ryen Agil, in front of a room of CISOs to describe vulnerabilities they had found and reported at the very start of their careers. The organisers framed it as a talent-pipeline question: how the industry creates pathways for young people to apply offensive-security curiosity responsibly. I heard it as a hiring-filter question. Every one of our security and platform requisitions in Dubai this year has carried the line “minimum 5 years’ experience”. It would have excluded both speakers, and it excludes the engineers most likely to have learned cryptography after 2024 rather than before it.

I have replaced the line with a work sample. Candidates get a small service with three deliberately hard-wired algorithm choices and forty minutes to produce an inventory and a plan; the five questions above are the debrief. Years of experience predicted performance on that exercise poorly in the first dozen candidates. Having done one real migration predicted it very well. Our guide to hiring junior developers in Dubai has the structure for bringing in the under-25 profile without lowering the bar; the exercise slots into step 4.

If You Also Run Engineering in Singapore

Singapore’s regulators have been running the same conversation with its banks, and the hiring profile is identical. Our Singapore team’s seven-step guide to hiring application security engineers in Singapore covers the interview loop for the security-titled version of this role, and their DevSecOps hiring guide for Singapore fintech is where the cryptographic inventory lives day to day once you have one. The five questions in this article work unchanged in both markets; only the regulator’s name on the questionnaire differs.

FAQ — GISEC 2026, Post-Quantum Cryptography and Hiring in Dubai