Emulation versus simulation: what the difference costs you
Both words appear in vendor decks. Only one of them tells you whether you would survive the real thing.
Two words, two questions
Emulation and simulation are often used as if they mean the same thing. They do not, and the difference matters when you are deciding where to spend a limited budget.
Simulation asks whether your controls respond to a known behaviour. Emulation asks whether your organisation would withstand a specific adversary. The first is a test of components. The second is a test of the whole.
What simulation tells you
Simulation runs individual techniques, usually in isolation and often automatically. A behaviour is triggered and the question is simple: did anything see it?
This is valuable. It is repeatable, it scales, and it is an efficient way to confirm that a detection still works after a change. Run regularly, it catches drift: the rule that was quietly disabled, the sensor that stopped reporting, the update that changed a log format.
What simulation cannot tell you is how those techniques combine. Adversaries do not perform a list of behaviours. They make choices, adapt to what they find and avoid what looks watched. A control that catches a technique in isolation can miss the same technique inside a patient, coherent operation.
What emulation tells you
Emulation starts with intelligence. We choose the adversaries most relevant to you, by sector, geography and the assets you hold, and study how they operate. Then we reproduce that tradecraft in sequence, with the same objectives and the same patience, against your live defences.
Every step is mapped to a shared framework, so the results speak a common language with your detection engineers. The unit of measurement is the whole operation. We are asking whether the adversary would have reached their goal, at which point they would have been noticed, and whether that notice would have led to action.
The answers are often uncomfortable. Detections that pass in simulation are sidestepped by sequencing. Alerts fire but are triaged away because, in context, the activity looked routine. Response begins, but too late to matter.
Where the cost hides
Simulation is cheaper per run. Emulation is cheaper per insight. The real cost lies in choosing the wrong one for the question you are trying to answer.
An organisation that relies only on simulation can build a reassuring dashboard of green ticks while remaining exposed to the adversaries most likely to come. An organisation that runs emulation once a year learns deeply but infrequently, and loses ground between operations as the environment changes.
The hidden cost is false confidence. It does not appear in a budget line. It appears later, at the worst possible moment.
Using both well
The two work best together. Emulation finds the gaps that matter and explains why they exist. Simulation then guards the fixes, running the relevant techniques regularly so that what was closed stays closed.
The sequence matters. Start with the question of who is likely to target you, and how. Let that drive the emulation. Let the emulation's findings decide what the simulation should check. Without that thread, simulation tends to test whatever is easiest to automate rather than whatever matters most.
What to do about it
Be precise about the question before you choose the method.
- Use emulation to answer whether you would withstand the adversaries most relevant to you.
- Use simulation to confirm, continuously, that the detections you rely on still work.
- Let intelligence about real adversaries decide what both of them test.