One cyber range cannot serve every sector — unless it is built as a framework.

Here is how the customer's year goes. You look at a cyber range. The demo is good. You sign. You install. You run the lab scenarios that come with it. The first quarter goes fine.

Six months in, your CISO asks for a scenario built around your own setup — your plant, your operators, your regulator, the threat actor your team is tracking. A fair ask. You have paid for a cyber range.

The reply is where the trouble starts. The vendor sends a Statement of Work. The number is large. Procurement takes three months to clear it. The vendor's engineering team is abroad. They can start in nine months. Delivery is nine months after that. By the time the scenario is ready, the threat picture has moved. The reporting clock has changed. The CISO who asked for it has moved on.

The Statement of Work is not the costly part. The costly part is what happens after two or three such cycles. The customer learns that custom work is slow and dear. So they stop asking.

After that, the same three or four lab scenarios are run for every new batch of trainees. Training stops getting better. The team's skill stops getting better. On paper the investment is fine. On the floor, it is not.

When we sit with the operator at the console and ask if she is happy with what is on the floor, we rarely get a clear yes. People do not write it on the customer survey. They tell us in the corridor, once the review is over.

From the threat-research side, the gap is worse. The tradecraft we track changes every quarter. The product on the customer's floor is updated once a year at best, and often less. By the time the range catches up, the actor has moved to a new method. The customer is rehearsing last year's incident.

There is also the question of which actors the product was built against. The ones we worry about in India — those going after our banks, our power utilities, our telecom networks, our defence — are not the same set the foreign products were built for. The names on the screen are wrong. The targeting is wrong. The timing is wrong. The exercise rehearses something. It does not rehearse your incident.

This is not the vendor being lazy. It is a shape problem. The product was built around a different customer — a utility in Pennsylvania, a SOC in Frankfurt, a C2 cell in Tysons Corner. It was not built around a substation in Raichur, a bank in Mumbai, or a tactical brigade in Ladakh.

When the Indian customer later asks the product to fit their setup, the product has to be opened up from outside. That seam — between the sealed product and the customer's real environment — is where every Indian customer ends up paying. In budget. In time. And worst of all, in the gap between what the rehearsal taught and what the real incident asked for.

We saw this at three or four customer sites and could not look past it any more. The brochure shows a finished product. A year on, the real artefact is a product with a side door attached. The product looks polished. The side door is where the disappointment collects.

Our position is simple. The customer should not be made to walk through a side door at all. We are not selling you a finished product that you will later need to bolt your reality on to. We are selling you the spine itself.

To put it plainly — your scenario authoring runs through the same code path our own scenarios run through. Your mission canvas is drawn by the same engine. Your adversary playbooks come from the same atomic-test library. Your compliance pack is on the same release train as everything else.

There is no side door, because there is no split between the platform's work and your work. Both go through the same interfaces, the same review, the same release.

Three things change for the buyer because of this. One — a new scenario for a new sector is in front of the trainees in weeks, not months. The framework already knows your operator language. Two — your custom work survives every later upgrade. It lives inside the platform, not on the side. There is no the integration broke after the last release conversation a year from now.

The third one matters most. Mayur, you should take that one.

The third one is that the threat-research work compounds across customers. When a customer in a sector flags tradecraft we have not seen before — a new way to move laterally, a new firmware exposure on a piece of plant equipment, a new phishing pattern aimed at the KYC desk — it lands inside the framework. On the next release, every other customer in that sector inherits the rehearsal for it.

This is not just a tick on a comparison sheet. It is a real advantage that grows with every engagement we run. A foreign product cannot copy it by adding a line to its roadmap — their customer in Raichur and their customer in Frankfurt do not share a release train at all.

One question — and ask it of the right person. One year after the cyber range goes in, not on demo day and not after the first quarter, walk down to the floor. Not the head of training. Not the procurement lead. The person at the console.

Ask her plainly: are you genuinely happy with what is on the floor today?

If the honest answer is anything other than yes, we would be glad to show you what a framework feels like. Not in a demo theatre — on your floor, with your people in the room. Send us a scenario you actually care about. The sector. The operator at the console. The regulator at the wall. The threat actor on your watch list. We will deploy it on real hardware in front of you.

The framework will take the work. The room will read the screen without a translator. The drill will land inside the clocks your auditor cares about. That is what the cyber range we have spent four years building was built to do.