Download the Book (PDF): Introduction Every security operations center runs on a quiet contradiction. The analysts who staff it are told that they are fighting human adversaries who adapt, improvise, and learn from their failures. Yet most of the tooling they are given treats the problem as a matter of matching strings. A file hash appears on a list; a connection is made to a flagged address; an alert fires. The work that follows is often little more than confirming that the match was real and then closing the ticket. This is not intelligence. It is pattern recognition with extra steps, and adversaries who understand how it works defeat it for the price of recompiling a binary or renting a new server. The gap between what security teams are promised and what they actually receive is the subject of this book. The promise is embedded in a phrase that has become ubiquitous: threat intelligence. Vendors sell it by the feed. Conferences devote tracks to it. Job titles now include it. And yet a great deal of what circulates under the name is not intelligence at all but raw data, stripped of the context that would let anyone decide whether it matters. A list of ten thousand malicious IP addresses is data. Knowing that a particular subset of those addresses belongs to infrastructure a specific intrusion set has used to stage ransomware against hospitals, that the addresses rotate every few days, and that blocking them outright will cost you nothing but blocking a related cloud range will break your own backups — that is intelligence. The difference is not academic. It determines whether the feed you ingest makes your defenses sharper or simply buries your analysts in noise. A threat intelligence platform, or TIP, is the machinery that closes this gap. At its most basic it is a system for collecting indicators and context from many sources, normalizing them into a common structure, enriching them with everything you already know, scoring them for relevance and confidence, and pushing the results into the controls that actually block, detect, and alert. Done well, a TIP turns the firehose of external data into a disciplined, auditable flow that makes the rest of the security stack more effective. Done badly, it becomes an expensive database that nobody trusts, feeding stale indicators into a firewall that occasionally blocks a customer. This book is written from the defensive side of the line. It assumes you work in or alongside a SOC, a computer security incident response team, a detection engineering group, or a threat intelligence function — or that you are responsible for standing one of these up. It does not teach offensive tradecraft, and it treats the adversary as a problem to be understood rather than admired. The orientation matters because almost every decision in threat intelligence work is a defensive trade-off: what to block versus what to merely watch, how long to trust an indicator, how much analyst time a given source is worth, how to share what you learn without exposing your own gaps. These are operational judgments, and this book is about how to make them well. The material rests on a small number of standards and models that have become the shared vocabulary of the field, and it is worth naming them at the outset because they recur throughout. STIX and TAXII, maintained by the OASIS standards body, define how threat information is structured and how it moves between systems; the current versions, STIX 2.1 and TAXII 2.1, became OASIS Standards in 2021 and are what any serious platform speaks today. The MITRE ATT&CK framework, now at version 18 as of its October 2025 release, catalogs the tactics and techniques adversaries use and gives defenders a common reference for describing behavior rather than mere artifacts. Older but still essential are the Lockheed Martin Cyber Kill Chain, the Diamond Model of Intrusion Analysis, and David Bianco's Pyramid of Pain, each of which supplies a way of thinking about indicators and adversaries that a platform should be built to support. On the sharing side, the Traffic Light Protocol, revised to version 2.0 by the Forum of Incident Response and Security Teams in 2022, governs how sensitive information is marked and passed between organizations. Two open-source platforms, MISP and OpenCTI, appear repeatedly as concrete examples because they are widely deployed, freely available, and representative of how these ideas are implemented in practice. It helps to have a concrete picture of the problem the book addresses. Imagine a mid-sized hospital network with a security team of four. They subscribe to two free indicator feeds, a sector sharing group, and one modest commercial feed, and together these deliver something on the order of several thousand new indicators a day. Without a platform, those indicators arrive as emails, CSV attachments, and web pages, and the team's options are all bad: ignore them, which wastes the subscriptions; paste them into the firewall by hand, which is slow and error-prone and will eventually block something it should not; or spend their scarce hours triaging a flood they can never get ahead of. With a platform but without discipline, the indicators are ingested automatically and pushed to the firewall automatically, and the first time a feed includes the address of the hospital's own cloud-hosted patient portal — captured during someone else's incident and mislabeled as malicious — the portal goes dark during a weekday morning, and the security team spends the next week rebuilding the trust they just lost. With a platform and discipline, the indicators are ingested, scored, enriched, checked against an allowlist that protects the hospital's own ranges and its major providers, aged so that stale entries expire, and pushed to the firewall only when confidence is high and impact has been weighed. The same raw material produces three completely different outcomes. The difference is entirely in the discipline, and the discipline is what this book teaches. None of this is useful as abstraction. The chapters that follow move deliberately from concept to mechanism to operation. The early chapters establish what intelligence is, what an indicator is, and why the structure of the indicator determines its value. The middle chapters cover the standards and analytic models that let a platform represent and reason about threats, and the practical matter of choosing and running a platform. The later chapters are about curation — the unglamorous, decisive work of deciding which indicators to keep, how to score them, when to retire them — and about operationalization, where intelligence either reaches the controls that matter or dies in a database. The automation of firewall blocklists serves as a running concrete example, because it is the point where a bad indicator causes visible, immediate harm and therefore forces every question about trust and confidence to the surface. A warning is in order about the central temptation of this field. Automation is both the goal and the hazard. The whole point of a platform is to remove human toil from the ingestion and distribution of indicators, so that analysts spend their time on analysis rather than copying addresses between consoles. But the same automation that lets a good indicator reach your firewall in seconds will, with equal speed and no hesitation, push a bad one there too. A single mislabeled entry in an upstream feed, ingested and auto-blocked without a confidence check, can take a company's own infrastructure offline. The discipline this book teaches is not how to automate everything, but how to automate the right things with the right safeguards, and to keep a human in the loop precisely where human judgment is irreplaceable. The organizations that do this well treat their platform not as an oracle but as an instrument — powerful, fast, and only as good as the hands guiding it. Chapter 1: From Data to Intelligence The word intelligence is borrowed, and the borrowing is instructive. It comes from the world of national security, where it names a specific discipline: the production of assessments that help a decision-maker act under uncertainty. An intelligence service does not simply collect facts. It collects them in service of questions that someone in authority needs answered, processes them into a usable form, analyzes them against what is already known, and delivers conclusions to the people who will act on them — and then listens to find out whether the conclusions were useful. This sequence, known as the intelligence cycle, predates computers by decades, and it is the single most important idea for anyone building a threat intelligence capability to internalize. Almost every failure in the field can be traced to skipping one of its steps. The cycle is usually described in five or six phases: direction, collection, processing, analysis, dissemination, and feedback. The names vary between doctrines, but the logic does not. Direction establishes what you are trying to learn. Collection gathers raw material against those requirements. Processing converts the raw material into a form that can be worked with — decrypting, translating, parsing, normalizing. Analysis interprets the processed material and produces an assessment. Dissemination delivers the assessment to whoever needs it, in a form they can use. Feedback closes the loop by establishing whether the product actually helped, which in turn reshapes the direction for the next cycle. A threat intelligence platform is, at bottom, a machine for running this cycle at scale and speed, and the quality of a program depends on whether its builders understood that the cycle is the point and the technology merely the means. The field's besetting sin is to begin at collection. An organization decides it needs threat intelligence, buys three or four feeds, stands up a platform to ingest them, and only then discovers that it has no idea what to do with four million indicators. This is collection without direction, and it produces exactly what you would expect: a vast store of data that answers no particular question, consumes analyst attention, and slowly erodes trust as its false positives accumulate. The correct order is the reverse. Before a single feed is purchased, someone must answer the question that drives everything else: what decisions are we trying to inform, and who makes them? Direction and the intelligence requirement Direction in a security context takes the form of intelligence requirements — explicit statements of what the organization needs to know in order to defend itself. A good requirement is specific enough to guide collection and to test whether collection succeeded. "Tell us about cyber threats" is not a requirement; it is a wish. "Which ransomware groups are currently targeting regional hospitals in our country, what initial-access techniques are they using, and what infrastructure and tooling do they rely on" is a requirement. It names a threat, a scope, and the kinds of answers that would satisfy it, and it points directly at the collection sources and analytic models that could produce those answers. Requirements fall naturally into three altitudes, and conflating them is a common mistake. Strategic intelligence serves executives and board members who make decisions about risk, investment, and posture over months and years; its products are assessments and briefings, not indicators, and its consumers rarely log into the platform at all. Operational intelligence serves the people who plan defenses and run incident response; it concerns the campaigns, intrusion sets, and techniques an organization is likely to face, and it is where frameworks like MITRE ATT&CK do their heaviest work. Tactical intelligence serves the machines and the analysts closest to them; it is the realm of indicators of compromise — hashes, addresses, domains — that feed directly into detection and blocking. A platform must serve all three, but the three have different consumers, different cadences, and different measures of success. A feed of ten thousand daily indicators is a tactical product; presenting it to a board as "our threat intelligence" is a category error that helps no one. The organizations that get direction right tend to run a deliberate process to produce and maintain their requirements, often called priority intelligence requirements, and to revisit them regularly as the business and the threat landscape change. The requirements are written down, owned by named people, and used as the yardstick against which collection sources are evaluated. When a new feed is proposed, the question is not "is this data good" in the abstract but "does this data help us answer one of our requirements." A feed of cryptocurrency-fraud indicators may be excellent and still be worthless to a hospital network with no financial-services exposure. Direction is what lets you say so without apology. Deriving requirements well means starting from the organization rather than from the threat catalog. The useful questions are concrete: what would hurt us most if it happened, what do we have that an adversary would want, and how would a competent attacker most plausibly come at us given our actual technology and exposure? A hospital's answers — disruption of clinical systems, theft of patient records, ransomware that halts care — point toward a specific set of adversaries and techniques, and therefore toward specific collection. A manufacturer's answers — theft of designs, sabotage of production, compromise of operational technology — point somewhere quite different. The requirements that result are not a generic list of fashionable threats but a tailored description of what this organization needs to watch, and they double as a filter: anything a feed or a report offers that does not bear on a requirement can be set aside with a clear conscience. The alternative, collecting against the industry's general anxieties rather than the organization's specific exposure, is how a program ends up tracking nation-state espionage techniques it will never face while missing the commodity phishing that actually breaches it every quarter. Collection, and the trap of more Collection is the gathering of raw material against requirements, and it is where the platform's ingestion machinery lives. Sources are conventionally grouped by type. Open-source intelligence includes public feeds, vendor blogs, security researchers' publications, and the enormous body of indicators shared freely by the community. Commercial intelligence comes from vendors who sell curated feeds and finished reporting, usually with better context and lower false-positive rates than free sources, at a price. Sharing-community intelligence flows through trust groups and sector-specific bodies — the information sharing and analysis centers, or ISACs — where members exchange what they see with peers who face the same adversaries. And internal intelligence, the most valuable and most neglected category, comes from the organization's own incident response, its logs, its honeypots, and its past investigations. An indicator that burned you last month, enriched with everything you learned while cleaning up the mess, is worth more than any feed, because it is specific to your actual adversaries and already contextualized by your own analysts. The trap in collection is the belief that more sources mean better intelligence. They do not. Each source carries a cost that is invisible on the invoice: the analyst time required to evaluate it, deduplicate it against everything else, resolve its conflicts, and investigate the false positives it generates. A free feed that produces a thousand indicators a day, of which five are relevant and fifty are false positives that trigger investigations, is not free. It is a standing tax on your analysts' attention, and it may well be a net loss. Consider the arithmetic that most programs never do. Suppose a free feed delivers eight hundred indicators a day. Over a month that is roughly twenty-four thousand indicators. If the feed's true-positive rate against your environment is a tenth of a percent — a generous figure for a generic public feed — you gain perhaps two dozen indicators a month that match something you actually care about. If its false-positive rate is even one percent, you generate on the order of two hundred and forty false matches a month, each of which, if it fires an alert, costs an analyst some minutes to dismiss. Two dozen useful hits against two hundred-odd false alarms is not obviously a good trade, and it becomes a clearly bad one if the feed is auto-blocking rather than merely alerting, because then the false positives are outages rather than annoyances. The same feed can be a net gain for an organization that uses it only to enrich and corroborate indicators it already has, and a net loss for one that blocks on it directly. The quality of a source cannot be judged in isolation from how the program uses it, which is why feed evaluation has to be tied to measured outcomes rather than to the vendor's description of its own data. The discipline of collection is subtractive as much as additive: knowing which sources to drop is as important as knowing which to add, and a mature program prunes its feeds regularly on the basis of measured value. The platform supports this by tracking, for every source, how many indicators it contributed, how many matched real activity, and how many turned out to be noise. Without that measurement, feed selection is superstition. Processing, analysis, and the human in the middle Processing is where the platform earns a large part of its keep, because the raw material arrives in a dozen incompatible shapes. One feed delivers a CSV of addresses; another a STIX bundle; another a PDF report that a human must read and extract from; another an email from a peer. Processing normalizes all of this into a common internal structure, resolves obvious duplicates, attaches provenance so that every indicator remembers where it came from, and prepares the material for analysis. The standards that make this possible — STIX for structure, TAXII for transport — are the subject of a later chapter; for now the point is that processing is mechanical, automatable, and essential, and that a platform which skips it forces its analysts to do the normalization by hand, one indicator at a time. Analysis is the step that cannot be fully automated, and the step that most distinguishes intelligence from data. It is where a human — assisted by the platform, never replaced by it — interprets the processed material against the organization's requirements and its existing knowledge. Analysis asks the questions that a machine cannot: Does this cluster of indicators represent the campaign we have been tracking, or a new one? Is this indicator a genuine threat or a sinkhole that a researcher stood up to study the malware? Does blocking this address protect us or break us? The platform supports analysis by assembling context — showing the analyst everything already known about an indicator and its relationships — but the judgment is human. Programs that try to eliminate the analyst, feeding raw data straight from collection to the firewall, discover the cost of the omission the first time a legitimate service lands on a blocklist. Analysis is also where the analytic models earn their place. An analyst confronted with a handful of indicators from a new report does not reason about them as a flat list; they ask where in the adversary's operation these indicators sit, which of the adversary's known techniques they correspond to, and how they relate to what the organization already knows about the actor. This is the point in the cycle where the Diamond Model, the kill chain, and MITRE ATT&CK — the subjects of a later chapter — do their work, and a platform that cannot support that kind of reasoning forces the analyst to do it in their head or on a whiteboard, which does not scale and does not persist. Good analysis leaves a trace: the assessment, the reasoning behind it, and the confidence attached to it are recorded in the platform so that the next analyst to meet the same indicators inherits the judgment rather than repeating the work. The failure to record analysis is a quieter cost than a firewall outage, but over time it is just as expensive, because it condemns the team to relearn the same conclusions every time an adversary reappears. Dissemination, feedback, and the loop that most teams never close Dissemination delivers the finished product to its consumers in a form they can use, and this is where tactical, operational, and strategic intelligence diverge most sharply. Tactical indicators are disseminated to machines — firewalls, intrusion-detection sensors, endpoint tools, SIEMs — through automated integrations that push vetted indicators into the controls in near-real time. Operational intelligence is disseminated to analysts and defenders as structured reporting, often mapped to ATT&CK so that defenders can reason about coverage. Strategic intelligence is disseminated to leadership as prose: assessments, briefings, and recommendations. A platform that can only disseminate to one audience is serving only one altitude of the cycle. Feedback is the step almost every program neglects, and its neglect is why so many threat intelligence functions stagnate. Feedback asks, of every product, whether it helped. Did the indicators we pushed to the firewall block real attacks, or did they generate false positives and nothing else? Did the operational report change how the detection team built their rules? Did the strategic briefing inform a decision? The answers reshape direction: feeds that never produce a hit are dropped, requirements that are consistently satisfied are retired, requirements that are consistently missed drive new collection. Without feedback, the cycle is not a cycle at all but a one-way pipe, and the program drifts further from relevance every month, measuring its own success by volume — indicators ingested, feeds subscribed — rather than by the only metric that matters, which is whether it helped someone defend the organization better than they could have without it. A concrete illustration shows how feedback reshapes a program. A team subscribes to four feeds and, after six months of disciplined measurement, can say that feed A produced the indicators behind three confirmed detections and almost no false positives; feed B produced a torrent of indicators, none of which ever matched real activity but many of which generated false alarms; feed C duplicated most of what feed A already supplied, a day later; and feed D produced nothing at all. The feedback is unambiguous: keep A, drop B, drop C as redundant, and reconsider whether D's requirement is being served by any source. A program without feedback keeps all four, because dropping a feed feels like losing capability, and so it carries the cost of B's noise and C's redundancy indefinitely, mistaking its growing subscription list for growing capability. The team that measures outcomes ends the year with fewer feeds, less noise, and better detections than the team that only ever added. The intelligence cycle is not a bureaucratic formality to be endured before the real work of ingesting feeds begins. It is the real work. The platform exists to run the cycle faster and at greater scale than humans could manage alone, but if the cycle is broken — if collection has no direction, if analysis is skipped, if feedback never closes the loop — then no platform, however expensive or sophisticated, will produce intelligence. It will produce data, in enormous and growing quantities, and call it intelligence, and the gap between the two will be paid for by the analysts who drown in it and the defenses that were supposed to improve. Chapter 2: Indicators of Compromise and the Pyramid of Pain An indicator of compromise is a piece of observable evidence that an intrusion has occurred or is underway. The canonical examples are concrete and familiar: the cryptographic hash of a malicious file, the address of a server the malware contacts, the domain name encoded in a phishing link, a distinctive string in a registry key, a particular user-agent that a piece of malware sends. Each is a fact that can be observed in logs, on disk, or on the wire, and each, if matched, suggests that something has gone wrong. Indicators are the atoms of tactical threat intelligence. They are what feeds carry, what platforms ingest, and what controls block. They are also, taken in isolation, the weakest form of intelligence there is, and understanding why is the beginning of understanding how to use them well. The weakness is not in the concept but in the ease with which most indicators can be changed. A file hash identifies one exact file; flip a single bit and the hash is entirely different, while the malware does exactly what it did before. An address identifies one server; the adversary rents another in minutes. A domain is slightly stickier — it must be registered and configured — but domains are cheap and disposable, and a motivated adversary cycles through hundreds. Each of these indicators, when you block it, costs the adversary almost nothing to replace. You have swatted at a single instance of a problem that regenerates faster than you can swat. This is the central frustration of indicator-based defense, and it is the frustration that David Bianco's Pyramid of Pain was built to make legible. The Pyramid of Pain In 2013, Bianco, then a detection and response practitioner, published a simple diagram that has since become one of the most cited ideas in the field. The Pyramid of Pain arranges the types of indicators by a single criterion: how much pain it causes the adversary when you deny them the use of that indicator. The insight is that not all indicators are equal, and that a defender's effort is best spent as high up the pyramid as possible, because that is where denial actually hurts. At the base of the pyramid sit hash values. Blocking a hash is trivial for you and trivial for the adversary to defeat — a recompile, a repacking, a single changed byte, and the hash is useless. One step up are IP addresses, easy for you to block and easy for the adversary to rotate, especially now that attackers stage through cloud providers and compromised hosts whose addresses are shared with legitimate services. Above addresses come domain names, which cost the adversary a little more because they must be registered and resolved, but not much. These bottom three tiers are what most feeds overwhelmingly consist of, and they are the indicators whose denial the adversary shrugs off. The pyramid changes character above this line. Network and host artifacts — the distinctive traces a specific tool leaves behind, such as a characteristic URI pattern, a particular sequence of registry modifications, or a telltale mutex — are harder for the adversary to change, because changing them means modifying the tool itself. Above artifacts sit tools: if you can detect and deny an entire tool the adversary relies on, you force them to find or build another, which costs real time and skill. And at the apex sit tactics, techniques, and procedures — the behaviors that express how the adversary actually operates, independent of any particular file or server. Denying a TTP is the hardest thing you can do to an adversary, because it attacks not their disposable infrastructure but their tradecraft, and forcing a skilled operator to change how they work — not merely what tools they use — imposes the greatest cost of all. The practical lesson of the pyramid is not that low-level indicators are worthless. A blocked hash still stops the specific file it names, and blocking known-bad infrastructure still raises the adversary's operating cost at the margin. The lesson is about where to invest finite effort. A program that measures its success by the volume of hashes and addresses it blocks is operating at the bottom of the pyramid, winning skirmishes the adversary barely notices. A program that invests in detecting behavior — that maps adversary activity to ATT&CK techniques and builds detections for the techniques rather than the artifacts — is operating at the top, and its wins are durable. The point of a threat intelligence platform is partly to automate the bottom of the pyramid so efficiently that analysts are freed to work at the top. A worked example makes the asymmetry vivid. Suppose an adversary delivers a loader by email, and you obtain its SHA-256 hash. You block the hash, and you have stopped exactly that file. The adversary recompiles with a trivial change — a different timestamp, a padded resource, an added no-op — and the new build has a completely different hash while behaving identically; your block is now worthless, and the cost to the adversary was a single build command. Now suppose instead that you identified a network artifact the loader produces: a distinctive, hardcoded sequence in the way it beacons to its controller, perhaps an unusual URI structure or a fixed, idiosyncratic user-agent string. To defeat a detection keyed on that artifact, the adversary must modify the loader's code and retest it, which costs more than a recompile. And suppose you went further and built a detection for the behavior — a process spawned from a document reaching out to a freshly registered domain and then establishing a persistent beacon on an unusual interval. To evade that, the adversary must change not a string but their whole approach to delivery and command-and-control, which may mean abandoning a tool they have invested in and relearning how they operate. The same intrusion, detected at three different levels of the pyramid, imposes three wildly different costs on the adversary for roughly comparable effort on your side. That is the entire argument for climbing. Table 1 summarizes the pyramid and what each level costs the two sides. Table 1. The Pyramid of Pain: indicator types and the cost of denial. Level Indicator type Cost to defender Pain to adversary when denied 1 (base) Hash values Trivial Trivial — recompile or repack 2 IP addresses Easy Easy — rotate infrastructure 3 Domain names Moderate Simple — register new domains 4 Network/host artifacts Moderate Annoying — modify the tool 5 Tools Hard Challenging — find or build new tooling 6 (apex) Tactics, techniques, procedures Hard Tough — change how they operate Indicator types in practice Within the tactical layer, indicators come in a handful of families that a platform must handle distinctly. File indicators are hashes, most usefully SHA-256; the older MD5 and SHA-1 still circulate widely in feeds despite being cryptographically broken for collision resistance, which matters less for indicator-matching than for other uses but is a reason to prefer SHA-256 where you can choose. Network indicators are addresses, domains, and full URLs, each with different handling: a URL is more specific than a domain, which is more specific than an address, and blocking at the wrong level of specificity is a frequent source of collateral damage. Email indicators include sender addresses, subject lines, and header artifacts used in phishing. Host indicators include file paths, registry keys, mutex names, and service names that a specific malware family creates. Each family maps to a different control — network indicators to firewalls and proxies, file indicators to endpoint tools, host indicators to EDR and forensic sweeps — and part of the platform's job is to route each indicator to the control that can act on it. The level of specificity at which a network indicator is expressed deserves particular care, because it is a common source of both missed detections and collateral damage. An address is the broadest network indicator: block it and you block every service on that address, which is precise when the address is a dedicated malicious server and catastrophic when it is a shared host. A domain is narrower: block it and you deny resolution of that name without touching other sites on the same address. A full URL is narrower still: it names a specific resource on a specific host, so that blocking it denies the malicious path while leaving the rest of the site reachable. The right level depends on what the adversary controls. If they own the whole server, the address is the right indicator and blocking it costs you nothing. If they have planted a malicious file in a corner of an otherwise legitimate, compromised website, the URL is the right indicator and blocking the address would take down an innocent site. A program that blocks everything at the address level because addresses are the easiest to handle will, sooner or later, block a shared host and harm a bystander; a program that only ever blocks at the URL level will miss the adversary who simply moves the file to a new path on the same server. Matching the specificity of the indicator to the scope of what the adversary actually controls is a small discipline with large consequences, and it is one a platform supports by carrying each network indicator at its proper type rather than flattening everything to addresses. A subtlety that trips up many programs is the distinction between an indicator and an observable. In the vocabulary that the STIX standard formalizes, an observable is a bare fact — this address, this hash — with no claim attached, while an indicator is an observable plus an assertion that it signifies something malicious, usually expressed as a pattern together with context about what it detects and for how long it is valid. The distinction is not pedantry. An address that appears in your logs is an observable; it becomes an indicator only when someone or something asserts that connecting to it is evidence of compromise. Conflating the two leads directly to the error of treating every address a feed mentions as something to block, when the feed may have included it as context, as a sinkhole, or as a legitimate service the malware abused. False positives, sinkholes, and the cost of being wrong The defining operational hazard of indicators is the false positive, and the firewall blocklist is where false positives do their most visible damage. A false positive occurs when an indicator matches something that is not, in fact, malicious. The causes are many and mostly mundane. A feed includes a shared hosting address, and you block a server that also hosts a thousand legitimate sites. A researcher sinkholes a malware family's command-and-control domain to study it, and the sinkhole address — now entirely benign, run by a security company — propagates through feeds as "malicious infrastructure," so that blocking it blocks nothing harmful while generating alerts every time an infected but harmless test machine phones home. A content delivery network's address appears in a feed because malware once used it, and you block a range that half the internet depends on, including your own software updates. The most expensive false positives are the ones that block your own organization. Cloud providers assign and reassign addresses constantly; an address that hosted a malicious staging server on Monday may host a legitimate customer — possibly you — by Friday. A feed that captured the address on Monday and never expired it will, if auto-blocked, take down whatever now lives there. This is not a hypothetical. Organizations have blocked their own services, their own backup infrastructure, and major cloud platforms wholesale by ingesting stale infrastructure indicators and pushing them to the firewall without a confidence check or an allowlist. The lesson is burned into every experienced analyst: automation without curation is a loaded weapon pointed at your own feet. The sinkhole case deserves particular attention because it inverts the usual intuition about what a feed is telling you. When researchers or law enforcement take over a malware family's command-and-control domain, they point it at a sinkhole — a server they control, which answers the infected machines' beacons so that the operators can study the botnet and, often, so that victims can be notified. The sinkhole address is therefore the opposite of dangerous: it is run by the good guys, and traffic to it is a sign that something on your network is infected and trying to reach its old controller. A naive feed that lists "malicious infrastructure" may include the sinkhole address, because the domain was once malicious, and a naive program that blocks it accomplishes nothing useful — the malware was going to talk to a researcher's server, not to an active controller — while also blinding itself to the very infection the beacon would have revealed. The sophisticated response is the reverse of blocking: a connection to a known sinkhole should raise a high-priority alert, because it means you have an infected host, and should emphatically not be dropped, because dropping it hides the problem. A program that cannot distinguish an active controller from a sinkhole treats a diagnostic signal as a threat and throws away the diagnosis. Defending against false positives is a curation problem, addressed at length in a later chapter, but the principles are worth stating here because they explain why indicators cannot simply be trusted. Every indicator needs a confidence score reflecting how sure the source is and how corroborated the indicator is. Every indicator needs an expiration, because infrastructure indicators decay fast and a six-month-old address is far more likely to be reassigned than malicious. Every automated blocking decision needs an allowlist of things that must never be blocked regardless of what a feed says — your own ranges, major cloud and CDN providers, critical dependencies. And high-impact actions, like adding an address to the perimeter firewall, deserve a higher confidence bar than low-impact ones, like raising an alert for an analyst to review. Why indicators are necessary but not sufficient The honest conclusion of a clear-eyed look at indicators is that they are necessary, useful, and fundamentally limited. They are necessary because the machines that defend a network operate on exact matches: a firewall blocks an address, not a "technique." They are useful because denying known-bad infrastructure genuinely raises the adversary's cost and stops the unsophisticated and the opportunistic. But they are limited because the sophisticated adversary — the one you most need to stop — treats the entire bottom of the pyramid as consumable, discarding and replacing hashes and addresses as fast as you can block them. Against that adversary, indicators buy you time and visibility, not victory. This is why the best programs treat indicator management as the floor of their ambition rather than the ceiling. They automate indicator ingestion, scoring, distribution, and expiration so thoroughly that the bottom of the pyramid runs itself, and they spend the human time thereby freed on the top of the pyramid: understanding the adversary's techniques, mapping them to a framework, and building detections that survive the adversary's next recompile. The indicator is the entry point to the adversary, not the adversary. A platform that helps you follow an indicator up to the campaign, the intrusion set, and the technique behind it is doing intelligence. A platform that merely counts indicators is doing inventory. The chapters that follow are about building the former. Chapter 3: STIX and TAXII, the Common Language The threat intelligence field had a problem that every young discipline has: everyone was writing the same things down in different ways. One vendor's feed called a malicious server an "IP"; another called it "ipv4-addr"; a third embedded it in a prose report that a human had to read. A domain was "domain" here, "fqdn" there, "hostname" somewhere else. Relationships between things — this malware uses that server, this campaign is run by that group — were expressed, when they were expressed at all, in whatever ad hoc structure each tool happened to use. The result was a Babel in which sharing intelligence between organizations meant writing a custom translator for every pair of systems, and in which the context that makes data into intelligence was routinely lost in translation. STIX and TAXII exist to end the Babel. STIX, the Structured Threat Information Expression, is a standard for what threat intelligence looks like — a common data model and serialization. TAXII, the Trusted Automated Exchange of Intelligence Information, is a standard for how it moves — a transport protocol for exchanging STIX. The two are developed together under the Cyber Threat Intelligence Technical Committee of OASIS, the international standards body, and the current versions, STIX 2.1 and TAXII 2.1, were approved as OASIS Standards in June 2021. They are the lingua franca of the field. A platform that cannot consume and produce STIX over TAXII is, in 2026, not a serious platform, and understanding the model is prerequisite to understanding how a platform represents and reasons about the intelligence it holds. The STIX graph The single most important thing to grasp about STIX 2.1 is that it describes a graph. Earlier intelligence formats tended to be flat lists — here are some bad addresses, here are some bad hashes — and flatness is exactly what strips indicators of their meaning. STIX instead models the world as a set of objects connected by relationships, so that an indicator is never a lonely string but a node embedded in a web of context: this indicator detects that malware, which is used by that intrusion set, which has been attributed to that threat actor, who has run that campaign, which targets that sector, using those attack patterns. The graph is the intelligence. The addresses and hashes are merely its most concrete nodes. STIX 2.1 moved the standard decisively to JSON, abandoning the XML of the 1.x line, which makes STIX content far easier for modern tools and programmers to work with. Every object carries a type, a globally unique identifier, timestamps for creation and modification, and a set of properties specific to its type. Because identifiers are globally unique, objects created by different organizations can refer to one another without collision, which is what makes genuine cross-organizational sharing possible: when a peer sends you a report, the indicators it references can be the very same objects, by identifier, that someone else already shared with you. The objects come in a few categories. STIX Domain Objects, or SDOs, are the higher-level concepts, and STIX 2.1 defines eighteen of them. They include the ones a tactical analyst meets daily — Indicator, Malware, Attack Pattern, Threat Actor, Intrusion Set, Campaign, Tool, Vulnerability — and the ones that hold analysis together — Identity, Infrastructure, Location, Report, Course of Action, Observed Data, Malware Analysis, Note, Opinion, and Grouping. Several of these, including Infrastructure, Location, Malware Analysis, Note, Opinion, and Grouping, were added in 2.1, reflecting the standard's maturation from a format for exchanging indicators into a format for exchanging reasoned analysis. The Opinion and Note objects, in particular, let one analyst disagree with another's assessment in a structured way, which is how real intelligence work proceeds — not by decree but by argued, attributed judgment. Beneath the SDOs sit STIX Cyber-observable Objects, or SCOs, which represent the bare facts: an IPv4 address, a domain name, a file with its hashes, a network traffic record, an email message. In STIX 2.1, these observables can stand on their own at the top level of a document rather than being trapped inside an Observed Data object, which was a meaningful improvement for representing raw telemetry. The distinction between an SCO and an Indicator restates, in the standard's own terms, the observable-versus-indicator point from the previous chapter: the SCO ipv4-addr is a bare address making no claim, while an Indicator object wraps that address in a STIX pattern and asserts that seeing it means something, with a stated validity window and confidence. Holding the graph together are STIX Relationship Objects, or SROs, of which there are two. The Relationship object is the generic edge: it connects a source object to a target object with a named relationship type, such as uses, indicates, attributed-to, targets, or mitigates. The Sighting object is special and underappreciated: it records that a particular piece of intelligence was actually seen — that this indicator fired, in this environment, at this time, this many times. Sightings are how the graph learns from reality. An indicator that a dozen organizations have sighted is a different proposition from one that no one has ever observed firing, and a platform that captures sightings can feed that signal back into confidence scoring and feed evaluation. A final structural piece is the STIX pattern, the little language in which an Indicator expresses what it detects. A pattern is not a bare value but an expression, so that an indicator can say "a file whose SHA-256 is X" or "network traffic to address Y on port Z" or compound conditions combining several observables. This is what lets a STIX indicator carry genuine detection logic rather than a naked string, and it is what a platform translates into the native rule language of each downstream control. It is worth seeing the shape of these objects in the concrete, because their structure is the structure of the intelligence. A minimal STIX Indicator object, in the JSON the standard uses, carries a type, an identifier, timestamps, a pattern, and a validity window: { "type": "indicator", "spec_version": "2.1", "id": "indicator--a1b2c3d4-...", "created": "2026-09-14T08:00:00.000Z", "modified": "2026-09-14T08:00:00.000Z", "name": "Known C2 domain for Example loader", "pattern": "[domain-name:value = 'bad-example-c2.test']", "pattern_type": "stix", "valid_from": "2026-09-14T08:00:00.000Z", "confidence": 85, "labels": ["malicious-activity"] } The confidence property, carried as an integer from 0 to 100, was formalized in STIX 2.1 and is central to everything the later chapters say about scoring and automated action. The valid_from field, and its optional companion valid_until, carry the indicator's lifetime — the standard's own acknowledgment that indicators decay. A separate Malware object would describe the loader itself, and a Relationship object of type indicates would connect the indicator to the malware, so that a consumer who matches the pattern knows not merely that something bad happened but what family it belongs to. This is the graph being built one object at a time, and it is why a STIX bundle is so much more than the CSV of domains it could have been. TAXII, the transport A perfect data model is useless if there is no agreed way to move it, and that is TAXII's job. TAXII 2.1 is a straightforward application-layer protocol built on HTTPS and REST, which was a deliberate design choice: by riding on the web's ordinary machinery, TAXII can traverse the firewalls and proxies that any real network imposes, and it can be implemented with the same tools and libraries that any web service uses. TLS is mandatory; intelligence in transit is always encrypted and the server always authenticated. The TAXII model is organized around a small set of concepts. A TAXII server hosts one or more API roots, which are logical groupings of content, each with its own URL — a single server might expose one API root for a public community and another, access-controlled, for a trusted group. Within an API root sit collections, which are the actual containers of STIX objects. A collection has a defined read and write posture, so a producer can offer a collection that consumers may read but not write to, while a sharing group might use a collection that trusted members can both read from and contribute to. Clients interact with collections through a handful of REST endpoints: a discovery endpoint that advertises what the server offers, endpoints to list and describe collections, an endpoint to retrieve the objects in a collection with filtering and pagination, an endpoint to add objects, and a status endpoint to track the progress of a submission. This request-response model — a consumer polls a collection and pulls the objects it does not yet have, filtered by time or type — is the heart of how TAXII 2.1 moves intelligence in practice. TAXII 2.0 had gestured at a second model, a publish-subscribe arrangement called channels in which a server would push content to subscribers as it arrived; TAXII 2.1 deferred that model, reserving the concept for future work while fully specifying only the collection-based request-response pattern. The practical consequence is that nearly all TAXII 2.1 exchange today is poll-based: your platform periodically asks each collection it subscribes to for everything new since it last checked, and ingests the results. The polling interval becomes an operational tuning parameter — frequent enough that fresh indicators arrive while they still matter, infrequent enough that you are not hammering a peer's server. The filtering and pagination that TAXII provides are more important than they first appear. A busy collection may hold millions of objects, and no consumer wants to re-download the entire collection on every poll. TAXII lets a client request only the objects added or modified since a given time, and it returns results in pages with markers that let the client resume where it left off, so that a daily poll fetches only the day's new material. This incremental, time-bounded retrieval is what makes subscribing to a large collection practical, and getting the bookkeeping right — recording the timestamp of the last successful poll per collection, handling the case where a poll fails partway through, deduplicating objects that arrive in overlapping pages — is a meaningful part of what a platform's ingestion layer actually does. A client that mishandles the incremental markers either misses objects, by advancing its marker past material it failed to fetch, or drowns, by re-fetching the whole collection every cycle. Access control sits naturally on this structure. Because an API root and its collections have URLs and require authentication, a producer can expose different collections to different audiences from the same server: a public collection of TLP:CLEAR indicators that anyone may read, a members-only collection for a sharing community, and a tightly held collection for a single trusted partner, each gated by the credentials the consumer presents. This is how a sharing community in practice maps its trust relationships onto the transport, and it is why TAXII's humble reliance on ordinary HTTPS authentication is a feature rather than a limitation — it inherits the whole mature apparatus of web access control rather than inventing a fragile new one. What the standard buys you, and what it does not The value of STIX and TAXII is interoperability, and interoperability is worth more than any single feature. Because MISP, OpenCTI, commercial platforms, government feeds, and ISAC distribution systems all speak STIX over TAXII, an organization can assemble intelligence from radically different sources and have it land in a common structure, and can share what it produces without building a custom integration for each partner. The standard also preserves context: because STIX models relationships, an organization that shares a report shares not just the indicators but the graph of malware, actors, and techniques around them, which is what lets the recipient decide whether the indicators matter to them. The Sighting object, underused as it is, deserves a second look as a bridge between the standard and the operational realities of later chapters. A Sighting does not merely record that an indicator exists; it records an encounter with that indicator in the real world — where it was seen, when, how many times, and by whom — and it can reference both the indicator sighted and the observed data that evidenced the sighting. In a mature exchange, sightings flow in both directions: a consumer who matches a shared indicator in their own environment can send a sighting back to the producer, telling them that their intelligence proved real and useful, and a producer who aggregates sightings from many consumers learns which of their indicators are actually firing in the wild. This feedback is exactly the signal that indicator scoring and feed evaluation depend on, and the fact that STIX provides a first-class object for it means the feedback can be exchanged between organizations in a structured way rather than being locked inside one platform. The reason sightings remain underused is cultural rather than technical: consumers are reluctant to reveal that an indicator fired in their environment, because doing so hints at what they have been targeted by, and so the sighting that would most help the community is the one an organization is most tempted to keep to itself. The same TLP machinery that governs the sharing of indicators governs the sharing of sightings, and a community that has built enough trust to exchange sightings has built something considerably more valuable than one that merely exchanges indicators. It is worth being candid about the standard's limits, because overselling it causes disappointment. STIX is expressive but verbose; representing a handful of indicators with full context produces a document far larger than a CSV of the same addresses, and the expressiveness is wasted if producers populate only the minimum fields. Much of the STIX in circulation is impoverished — indicators with no relationships, no confidence, no context — because a feed converted a flat list into STIX objects mechanically without adding any of the graph that gives STIX its value. The standard gives you a language capable of expressing rich intelligence; it does not guarantee that anyone has anything rich to say. And the standard's richness imposes a processing burden: a platform must parse, validate, deduplicate, and reconcile STIX objects whose identifiers and versions must be tracked carefully, because the same object can arrive repeatedly in updated versions and the platform must know which is current. The versioning discipline deserves a concrete word, because it is where naive implementations quietly corrupt their own data. In STIX, an object is identified by its id, and when the object changes — a new relationship is learned, confidence is revised, a validity window is extended — the producer issues a new version of the same object, carrying the same id but a later modified timestamp. A consuming platform must recognize that the arriving object is a new version of one it already holds, not a separate object, and must keep the latest version as current while ideally retaining the history. Get this wrong in one direction and the platform treats each version as a distinct object, so a single indicator revised five times becomes five indicators cluttering the graph; get it wrong in the other and a stale version overwrites a fresh one because the platform compared the wrong field. The standard specifies the rules precisely for exactly this reason, and a platform's fidelity to them is one of the less visible but more consequential measures of its quality, because the errors it produces are silent — no alert fires when a knowledge base slowly fills with duplicate or stale objects, and the degradation is noticed, if at all, only when an analyst stops trusting what the platform tells them. None of this detracts from the central achievement. Before STIX and TAXII, sharing threat intelligence at scale and across organizations was a bespoke engineering project every time. After them, it is a matter of pointing your platform at a collection and authenticating. The standards are not glamorous, and most analysts interact with them only through the platform that hides their machinery, but they are the substrate on which the entire exchange of threat intelligence now rests. A working knowledge of the STIX graph in particular — objects, relationships, sightings, the observable-versus-indicator distinction — is the difference between an analyst who understands why their platform represents the world as it does and one who merely clicks through its screens. Hashtags: #ThreatIntelligencePlatforms #ThreatIntelligence #AutomatedIOCIngestion #IndicatorAnalysis #IndicatorsOfCompromise #IntelligenceCycle #PriorityIntelligenceRequirements #ThreatDataNormalization #ThreatEnrichment #IndicatorScoring #ConfidenceScoring #IndicatorExpiration #STIX #TAXII #MITREATTACK #PyramidOfPain #CyberThreatIntelligence #ThreatIntelligenceSharing #MISP #OpenCTI #ThreatIntelligenceAutomation #FirewallBlocklists #HumanInTheLoop #DetectionEngineering #FutureOfThreatIntelligence

Download the Book (PDF): Introduction: Beyond the Alert For most of the history of security operations, defense has been a matter of waiting. The organization builds its defenses, deploys its detection systems, and waits for them to raise an alarm — waits for the alert that says an attack has been detected, and then responds. This is reactive defense, and it has a comforting logic: build good detection, wait for it to catch attacks, respond when it does. The security team sits watching its screens, waiting for the alerts to appear, responding to each as it comes. The model is reactive by design, and for a long time it was the whole of security operations: detect and respond, with the detection doing the finding and the team doing the responding. There is a problem with waiting, and it is a serious one: the attacks that matter most are often the ones the detection does not catch. Automated detection is valuable, and it catches a great deal, but it catches what it was built to catch — the known, the recognized, the things the detection was configured to find. The sophisticated adversary, the novel attack, the threat that operates in ways the detection does not recognize — these slip past the automated detection, raising no alert, triggering no alarm, because the detection was not built to catch them. And so the organization that waits for alerts is blind to exactly the threats that most endanger it: the sophisticated adversaries who operate beneath the detection, present in the organization's systems, undetected, because no alert fired to reveal them. The waiting defense catches the attacks it can catch and remains blind to the ones it cannot, which are often the most dangerous. Threat hunting is the answer to this problem, and it rests on a change of posture as simple to state as it is profound to adopt: instead of waiting for alerts, go looking. Threat hunting is the proactive search for adversaries that the automated detection missed — the active hunt through the organization's systems for the signs of attackers who are present but undetected, conducted on the assumption that such attackers may well be there, rather than on the hope that the detection would have caught them. The hunter does not wait for the alert; the hunter goes looking for the attacker the alert did not catch, searching proactively for the threats that slip past the automated detection, finding the adversaries that the waiting defense would have missed. This is the essence of threat hunting: proactive searching rather than reactive waiting, hunting for the undetected rather than responding to the detected. This booklet is about that discipline — what threat hunting is, how it is done, and why it matters — and its central argument can be stated at the outset: automated detection, however good, is not enough, and the proactive hunt for what the detection missed is a necessary complement to it. The organization that relies solely on automated detection is blind to the threats the detection does not catch, which are often the most dangerous, and the hunt is how it finds them. This is not to disparage automated detection, which is valuable and necessary; it is to say that detection alone leaves a gap — the gap of the undetected threats — and that threat hunting fills that gap by actively searching for what the detection missed. The hunt complements the detection, finding the threats the detection cannot, so that the organization is not blind to the sophisticated adversaries who operate beneath its automated defenses. The booklet builds the understanding of threat hunting systematically. It begins with the assumption that changes everything — the assume-breach posture that motivates the hunt, the recognition that an undetected attacker may already be present, which transforms waiting into searching. It establishes what hunting is and is not — the hypothesis-driven, proactive discipline, distinguished from the reactive detection it complements. It addresses the data to hunt in — the telemetry and logs that the hunt searches, without which there is nothing to hunt in. It develops the practice of hunting by hypothesis — forming and testing the hypotheses that direct the hunt, informed by the understanding of how adversaries operate. It examines the behavioral thinking that makes hunting effective — the focus on adversary behavior rather than superficial indicators, and the pyramid of pain that explains why behavior matters. It surveys the tools of the hunt — the platforms and capabilities that the hunter uses. It shows how the hunt feeds detection — the virtuous cycle in which hunting discoveries become automated detection, improving the detection over time. And it addresses building a hunting capability — the program, people, and maturity that sustain the hunt. A word about audience and orientation. This booklet is written for the people who defend organizations and want to understand threat hunting — the security professionals, the defenders, the leaders who must decide whether and how to hunt, the aspiring hunters who want to understand the discipline. It assumes familiarity with security operations but not prior expertise in hunting, and it explains the concepts it needs. It is entirely defensive in orientation, concerned with the proactive defense that hunting provides, and it treats hunting as what it is: a discipline of defenders, searching for adversaries in order to find and counter them. It is honest about the difficulty, because threat hunting is demanding — requiring skill, good data, and a particular proactive mindset — but also about the value, because hunting finds the threats that would otherwise go undetected, which is among the most valuable things a defense can do. It is worth clarifying, too, how hunting relates to the incident response that the title pairs it with, because the two are connected in a way that illuminates both. Incident response is what an organization does when it knows it has an incident — when a threat has been detected or discovered, and the organization must respond to it. Hunting is, in part, how the organization discovers the incidents that its detection did not reveal — the proactive search that finds the undetected threats, which then become incidents to respond to. Hunting thus feeds incident response, discovering the threats that response then addresses, so that the two work together: hunting finds the undetected threats, and incident response addresses them, the hunting proactively discovering what the response reactively addresses. And the skills overlap — the investigative skills of hunting and of incident response are related, both involving the investigation of adversary activity — so that hunters and incident responders share much, and the capabilities reinforce each other. Hunting and incident response are thus companion disciplines, the proactive hunting discovering the threats that the reactive response addresses, connected by the threats that hunting finds and response handles, and by the investigative skills they share. This booklet focuses on the hunting — the proactive discovery — while recognizing its connection to the response that addresses what the hunting finds, because the proactive hunting and the reactive response together form the fuller defense that finds and addresses the threats, including the undetected ones that only hunting discovers. One framing recurs throughout and is worth stating now: hunting assumes the adversary is already there. This assumption — that an undetected attacker may already be present in the organization's systems — is what transforms the defense from reactive to proactive, from waiting to searching. The organization that assumes its detection caught everything waits passively, confident it would know if an attacker were present; the organization that assumes an attacker may be present despite the detection hunts actively, searching for the attacker the detection missed. This assumption is the foundation of hunting, the posture that motivates the proactive search, and it is, this booklet will argue, the realistic assumption — because sophisticated adversaries do operate beneath automated detection, and the organization that assumes otherwise is blind to them. Hunting begins with the assumption that the adversary is already there, and goes looking, which is the proactive posture that finds what the waiting defense would miss. Chapter 1: The Assumption That Changes Everything Every defensive posture rests on an assumption about the adversary, and the assumption determines the posture. The reactive defense that waits for alerts rests on an implicit assumption: that if an attacker were present, the detection would have caught them, so the absence of alerts means the absence of attackers. Threat hunting rests on the opposite assumption: that an attacker may be present despite the absence of alerts, because the detection does not catch everything, so the absence of alerts does not mean the absence of attackers. This single difference in assumption — whether the absence of alerts means safety or merely means the detection has not caught anything — is what separates reactive defense from proactive hunting, and it changes everything about how the defense operates. This chapter is about that assumption: why the reactive assumption is false, why the hunting assumption is realistic, and how adopting the hunting assumption transforms the defense. The comforting falsehood The reactive assumption is comforting, and that is part of why it persists. It tells the organization that its detection is sufficient — that if an attacker were present, the detection would reveal them, so the quiet of no alerts is the quiet of safety. The security team watching its screens, seeing no alerts, can believe that all is well, that the absence of alarms means the absence of attackers, that the detection is doing its job and catching what there is to catch. This belief is comfortable, requiring nothing more of the team than watching and waiting, confident that the detection would reveal any threat. And it is false, dangerously so, because the detection does not catch everything, and the absence of alerts does not mean the absence of attackers but merely the absence of attackers the detection recognized. The falsehood lies in the assumption that the detection catches everything, which it does not. Automated detection catches what it was built to catch — the known threats, the recognized patterns, the attacks the detection was configured to find. But the sophisticated adversary operates in ways the detection does not recognize, deliberately avoiding the patterns the detection looks for, blending in with normal activity, using techniques the detection was not built to catch. Such an adversary is present but undetected, operating beneath the detection, raising no alert because the detection does not recognize them. The absence of alerts, for such an adversary, means not that they are absent but that they are undetected — present and operating, but beneath the detection that would have revealed a less sophisticated attacker. The reactive assumption, that no alerts means no attackers, is false precisely for the sophisticated adversaries who matter most, because they are the ones who operate beneath the detection, present but unalerted. This falsehood is dangerous because it breeds the complacency that lets the undetected adversary operate undisturbed. The organization that believes no alerts means safety does nothing to find the undetected adversary, confident there is none, while the adversary operates beneath the detection, undisturbed because the organization is not looking. The comforting falsehood, in other words, is exactly what the sophisticated adversary relies on: the organization's confidence that the detection would have caught them, which leads the organization not to look, which lets the adversary operate undetected. The adversary who evades the detection is protected not only by evading the detection but by the organization's false confidence that the detection would have caught them, which prevents the organization from looking for the adversary the detection missed. The realistic assumption The hunting assumption — that an attacker may be present despite the absence of alerts — is uncomfortable but realistic, and adopting it is the foundation of proactive defense. It rests on the recognition that detection does not catch everything, that sophisticated adversaries operate beneath detection, that the absence of alerts does not mean the absence of attackers but only the absence of detected attackers. This assumption is realistic because it is true: sophisticated adversaries do operate beneath automated detection, present but undetected, and the organization that assumes otherwise is blind to them. The hunting assumption faces this reality, assuming that an undetected attacker may be present, which is the realistic assumption given that detection does not catch everything. This assumption is sometimes called the assume-breach posture — the assumption that the organization may already be breached, that an attacker may already be present, despite the defenses and the absence of alerts. It is a posture of realistic humility about the defenses, recognizing that they do not catch everything and that an attacker may have gotten past them, rather than a posture of false confidence that the defenses caught everything. The assume-breach posture does not mean assuming the organization is definitely breached, but assuming it may be — holding open the realistic possibility of an undetected breach, and acting on that possibility by looking for the breach the detection may have missed. This realistic humility, this assumption that a breach may have occurred despite the defenses, is what motivates the hunt: because a breach may have occurred, the organization looks for it, rather than assuming the defenses caught everything and not looking. The assume-breach posture is realistic not pessimistic, and the distinction matters. It is not pessimism to recognize that detection does not catch everything and that an attacker may be present; it is realism, facing the true limits of detection rather than the comforting falsehood that detection is sufficient. The pessimist assumes the worst; the realist assumes what is actually likely, which is that detection has limits and an attacker may have exploited them. The assume-breach posture is realism about the limits of detection, and it leads to the proactive defense that those limits require — the hunt for what the detection missed, motivated by the realistic recognition that the detection may have missed something. Two organizations, one adversary The difference the assumption makes becomes vivid in the contrast between two organizations facing the same undetected adversary, differing only in their assumption. Both have been penetrated by a sophisticated adversary who operates beneath their detection — present in their systems, operating carefully, raising no alerts because the adversary deliberately avoids the patterns the detection looks for. The adversary is equally present in both organizations, equally undetected by both organizations' detection. What differs is the assumption, and the difference determines whether the adversary is found. The first organization holds the reactive assumption — that no alerts means no attackers, that its detection would have caught any threat. Seeing no alerts, this organization concludes it is safe, that no adversary is present, because the detection has revealed none. It does nothing to find the adversary, confident there is none, while the adversary operates beneath its detection, undisturbed because the organization is not looking. The adversary, present and undetected, continues to operate — advancing toward their goal, stealing what they came for, deepening their presence — unopposed, because the organization, assuming its detection would have caught any threat, does not look for the threat its detection missed. The adversary's evasion of the detection, combined with the organization's false confidence that the detection would have caught any threat, lets the adversary operate undisturbed, found only if they eventually make a mistake the detection catches, or never. The second organization holds the hunting assumption — that an attacker may be present despite the absence of alerts, that its detection does not catch everything. Despite seeing no alerts, this organization does not conclude it is safe; it assumes an adversary may be present that the detection missed, and it goes looking, hunting for the adversary the detection did not reveal. The hunters search the organization's systems for the signs of an adversary operating beneath the detection, hypothesizing about how such an adversary might operate and searching for the signs. And they find the adversary — the same adversary that the first organization did not find, present and undetected, revealed by the hunt that went looking for what the detection missed. The adversary's evasion of the detection does not protect them from the hunt, because the hunt does not rely on the detection, going looking for the adversary the detection missed, and finding them. Same adversary, equally present and undetected in both organizations — and one organization remains oblivious while the other finds the adversary, the difference being entirely the assumption. The first organization, assuming its detection would have caught any threat, does not look, and does not find the adversary its detection missed; the second organization, assuming an adversary may be present despite the detection, looks, and finds the adversary. This contrast is the whole case for the hunting assumption in one comparison: the sophisticated adversary who evades detection is found only by the organization that assumes they may be present and goes looking, while the organization that assumes its detection would have caught them remains oblivious. The assumption determines whether the organization looks, and looking determines whether the undetected adversary is found. How the assumption transforms the defense Adopting the hunting assumption transforms the defense from reactive to proactive, and the transformation is profound. The reactive defense, assuming no alerts means safety, waits passively, doing nothing to find threats beyond watching for alerts. The proactive defense, assuming an attacker may be present despite the absence of alerts, searches actively, going looking for the threats the detection missed. The difference is the difference between waiting and searching, between passive confidence that the detection would catch any threat and active investigation of whether a threat is present despite the detection. The assumption changes the defense from one that waits for threats to reveal themselves through alerts to one that actively searches for threats that have not revealed themselves, which is the transformation from reactive detection to proactive hunting. This transformation is consequential because it addresses the gap that reactive defense leaves. The reactive defense is blind to the undetected threats, catching only what the detection catches and missing what it does not; the proactive defense searches for the undetected threats, finding what the detection missed. By adopting the hunting assumption and searching actively, the organization fills the gap that reactive defense leaves, finding the sophisticated adversaries who operate beneath the detection, who the reactive defense would have missed. The transformation from reactive to proactive, driven by the change in assumption, is what lets the organization find the threats that its detection cannot catch, which is the whole value of hunting. The transformation also changes the mindset of the defenders, from watchers to hunters. The reactive defender watches, waiting for alerts, responding to what the detection reveals. The proactive hunter searches, actively looking for the threats that have not revealed themselves, pursuing the adversary the detection missed. This is a different mindset — active rather than passive, searching rather than waiting, pursuing rather than responding — and it is the mindset that the hunting assumption produces: because the hunter assumes an attacker may be present despite the absence of alerts, the hunter goes looking, actively, with the mindset of pursuit rather than the mindset of waiting. Why the assumption is not defeatist A natural objection to the assume-breach posture is that it seems defeatist — that assuming the organization may already be breached seems to give up on prevention, to accept defeat, to abandon the effort to keep attackers out. This objection misunderstands the posture, and addressing it clarifies what the assumption actually means and why it strengthens rather than abandons the defense. The assume-breach posture does not abandon prevention; it complements it. The organization that assumes it may be breached still works to prevent breaches, still deploys the detection that catches what it can, still does everything to keep attackers out — and additionally assumes that, despite all this, a breach may have occurred, and goes looking for it. The assumption is not instead of prevention but in addition to it, recognizing that prevention is imperfect and complementing it with the hunt for what prevention and detection missed. The organization holds both: the effort to prevent breaches, and the realistic assumption that prevention may have failed, which motivates the hunt. This is not defeatism but realism combined with proactivity — the realistic recognition that prevention is imperfect, combined with the proactive hunt for what imperfect prevention let through. Far from being defeatist, the assume-breach posture is the opposite of giving up: it is the refusal to be complacent, the refusal to assume the prevention worked, the active pursuit of the threats that complacency would ignore. The defeatist attitude would be to assume the breach cannot be found and not look; the assume-breach posture assumes the breach may be present and actively looks, pursuing the threat rather than ignoring it. The posture is active, not passive — it motivates the hunt, the active search, the pursuit of the adversary — which is the opposite of giving up. The organization that holds the assume-breach posture is more active in its defense, not less, adding the proactive hunt to the preventive and detective efforts, pursuing the threats that the others missed rather than assuming they do not exist. The assumption, rightly understood, is not defeatism but an additional, proactive layer of defense, complementing prevention and detection with the hunt for what they missed, which strengthens the defense rather than abandoning it. This hunter's mindset, produced by the hunting assumption, is central to the discipline, and the chapters that follow develop how the hunter, having adopted the assumption and the mindset, actually conducts the hunt — what hunting is, how it is done, and how it finds the threats the detection missed. But it all begins here, with the assumption that changes everything: that the adversary may already be there, undetected, and that the defense must go looking rather than wait. That assumption, realistic and uncomfortable, is the foundation of the proactive defense that hunting provides, and adopting it is the first step from waiting to hunting. Chapter 2: What Hunting Is, and Is Not The term "threat hunting" has become popular enough that it is applied to many things, not all of which are actually hunting, and the first task in understanding the discipline is to be clear about what hunting is and what it is not. Hunting is not merely monitoring, not merely responding to alerts, not merely running automated detection, though it is sometimes confused with all of these. Hunting is a specific thing — the proactive, hypothesis-driven search for undetected adversaries — and understanding what distinguishes it from the things it is confused with is essential to understanding the discipline. This chapter defines hunting precisely, distinguishes it from what it is not, and describes the hunting process, so that the reader understands what hunting actually is before the later chapters develop how it is done. Hunting is proactive The first defining characteristic of hunting is that it is proactive, and this distinguishes it from the reactive activities it is confused with. Hunting does not wait for something to happen and then respond; it goes looking, actively, before anything has prompted it. This is the essence of the proactive posture the previous chapter described: the hunter searches for the adversary without waiting for an alert to reveal the adversary, going looking on the assumption that an undetected adversary may be present, rather than waiting for the adversary to be revealed. This proactivity distinguishes hunting from reactive detection and response. Reactive detection waits for the detection to fire, then responds to what it reveals; hunting searches proactively, before any detection has fired, for the adversary the detection has not revealed. The reactive activity is prompted by an alert; the hunting activity is prompted by nothing but the hunter's decision to search, undertaken proactively rather than in response to a trigger. This is why hunting is a complement to reactive detection rather than the same thing: reactive detection catches what triggers it, while hunting searches for what has not triggered anything, the two addressing different threats — detection the ones that trigger it, hunting the ones that do not. The proactivity of hunting is what lets it find the undetected threats, which by definition have not triggered the detection, and so can be found only by proactive searching rather than reactive waiting. The proactivity also means hunting is not merely monitoring. Monitoring watches for things to happen, waiting to notice them; hunting searches for things that have already happened but have not been noticed, actively looking for the signs of an adversary already present. The monitor watches and waits; the hunter searches and pursues. Monitoring is valuable, but it is reactive in the sense that it waits to notice; hunting is proactive in that it actively searches for what has not been noticed. This distinction matters because organizations sometimes call their monitoring "hunting," believing that watching for threats is hunting, when hunting is the active search for threats already present but unnoticed, which is more than monitoring's watchful waiting. Hunting is hypothesis-driven The second defining characteristic of hunting is that it is hypothesis-driven, and this distinguishes it from aimless searching and from automated detection alike. Hunting is not a random search through the data, hoping to stumble on something; it is a directed search, guided by hypotheses about what an adversary might be doing, which focus the search and make it productive. The hunter forms a hypothesis — a specific idea about what an adversary might be doing in the environment, how they might be operating, what signs they might be leaving — and then searches to test the hypothesis, looking for the signs that would confirm or refute it. The hypothesis directs the search, focusing it on the specific thing the hypothesis concerns, making it a directed investigation rather than an aimless hunt. This hypothesis-driven nature is what makes hunting productive, because aimless searching through the vast data of a modern environment would be hopeless — there is too much data to search without direction, and a search without a hypothesis to direct it would be lost in the volume. The hypothesis provides the direction, focusing the search on the specific thing it concerns, so that the hunter searches for something specific rather than searching aimlessly. The hunter who hypothesizes that an adversary might be operating in a certain way searches for the signs of that specific way of operating, a focused search that the hypothesis makes productive, rather than an aimless search through all the data that would be hopeless. The hypothesis is the hunter's direction, and the hypothesis-driven search is what makes the hunt productive against the vast data of the environment. The hypothesis-driven nature also distinguishes hunting from automated detection. Automated detection looks for predefined things — the known patterns it was configured to find — mechanically, without hypotheses. Hunting forms new hypotheses, about what an adversary might be doing that the detection does not look for, and searches to test them, going beyond the predefined patterns to investigate new possibilities. The automated detection finds what it was built to find; the hunter hypothesizes about what the detection does not look for and searches for that, extending the search beyond the predefined to the hypothesized. This is why hunting finds what detection misses: the detection looks for the predefined, while the hunter hypothesizes about and searches for the undefined, the things the detection does not look for, which is where the undetected adversary operates. The hypothesis-driven search for what the detection does not look for is how hunting finds the undetected, and it is central to what distinguishes hunting from the automated detection it complements. The hunt as a process Hunting, done well, follows a process — a loop of forming hypotheses, searching to test them, investigating what the search reveals, and learning from the results — and understanding this process clarifies how hunting actually works. The process is not rigid, but it has a characteristic shape, moving from hypothesis through investigation to outcome, and the hunter moves through it repeatedly, hunt after hunt. A hunt, illustrated To make the process concrete, consider an illustrative hunt, told at the level of how it proceeds rather than analyzing any specific environment, showing how the process moves from hypothesis through search to outcome and learning. The illustration conveys the shape of a hunt, how its parts fit together into the process the discipline follows. The hunt begins when the hunter forms a hypothesis — suppose, informed by an understanding of how adversaries operate, the hunter hypothesizes that an adversary, if present, might be using a particular technique to operate in the environment, a technique the detection does not look for. This hypothesis — that an adversary might be using this specific technique — gives the hunt its direction: the hunt will investigate whether an adversary is using this technique, searching for the signs the technique would leave. The hypothesis is specific (a particular technique), grounded (based on how adversaries operate), and testable (the technique leaves signs the data captures), making it a good hypothesis that directs a focused hunt. The hunter proceeds to the search, investigating the data for the signs the technique would leave. The technique, if an adversary were using it, would leave particular traces in the data — the signs of the technique's activity, which would be in the data if the technique were used. The hunter searches the relevant data for these signs, querying the data for the traces the technique would produce, investigating whether the technique is being used in the environment. This search, directed by the hypothesis toward the specific signs of the specific technique, is focused and productive, looking for a particular thing rather than searching aimlessly. The hunter searches, and the search yields an outcome. Suppose the search finds something — signs consistent with the technique, suggesting an adversary may be using it. The hunter investigates further, examining the signs to determine whether they are in fact an adversary using the technique or a benign explanation, pursuing the investigation to resolve what the signs mean. Suppose the investigation confirms it: an adversary is using the technique, present in the environment, undetected until the hunt found them. The hunt has succeeded in its primary purpose, finding an undetected adversary, and the finding feeds the response that addresses the threat — the adversary found by the hunt is now addressed, caught by the hunt that went looking for what the detection missed. And the hunt feeds learning. The hunt learned how the adversary operated — the technique they used, the signs it left — which can inform detection to catch the technique automatically in the future, as the virtuous cycle a later chapter describes. The hunt that found the adversary by effort teaches how to catch that technique automatically thereafter, so the finding becomes lasting detection, and the hunt's value extends beyond the immediate finding to the detection it feeds. This is the process complete — hypothesis, search, outcome, learning — and the hunter proceeds to the next hypothesis, beginning the process again. The illustration shows how the process actually works, moving from the hypothesis that directs the hunt, through the search that tests it, to the outcome that finds the adversary and the learning that feeds the detection, which is the shape of hunting that the discipline follows, hunt after hunt. The hunt begins with a hypothesis — an idea about what an adversary might be doing, formed from the hunter's understanding of how adversaries operate, from the threats the organization faces, from the hunter's knowledge and intuition. This hypothesis, which the next chapters develop how to form, directs the hunt, giving it a specific thing to investigate. From the hypothesis, the hunt proceeds to the search — the investigation of the data to test the hypothesis, looking for the signs that would confirm or refute it. The hunter searches the relevant data for the signs the hypothesis predicts, investigating whether the adversary the hypothesis concerns is in fact present. This search, directed by the hypothesis, is the core of the hunt, where the hunter actually looks for the adversary. The search yields an outcome, and the hunt proceeds to investigating and acting on it. Sometimes the search finds something — signs of an adversary, confirming the hypothesis, revealing a threat that was present but undetected. When this happens, the hunt has succeeded in its primary purpose, finding an undetected threat, and the finding feeds the response that addresses the threat. Sometimes the search finds nothing — no signs of the hypothesized adversary, suggesting the hypothesis was wrong or the adversary is not present. This is not a failure, though it may feel like one, because the hunt that finds nothing still produces value, as the next point explains. Either way, the hunt yields an outcome — a found threat or a tested hypothesis — and the hunt proceeds to learning from it. The final part of the process is learning, and it is where the hunt produces lasting value beyond the immediate outcome. The hunt that found a threat teaches how the threat operated, which can inform detection to catch it automatically in the future, as a later chapter develops. The hunt that found nothing teaches that the hypothesized threat was not present, which is itself valuable knowledge, and may refine the hunter's understanding. Both outcomes feed learning — the found threat teaching how to detect it, the empty hunt teaching what is not present — and the learning improves the organization's defense over time, turning each hunt into a contribution to the defense beyond its immediate outcome. Why the empty hunt is not a failure A point worth dwelling on, because it is easy to misunderstand and important to morale and to the discipline's proper practice, is that the hunt that finds nothing is not a failure. It is natural to feel that a hunt that finds no adversary has failed — that the point of hunting is to find adversaries, so a hunt that finds none has not achieved its point. But this is a misunderstanding of what hunting produces, and correcting it is important both for the hunters' morale and for the proper practice of the discipline. The hunt that finds nothing produces real value, in several forms. It produces knowledge — the knowledge that the hypothesized adversary activity is not present, which is genuine information about the state of the environment, reducing the uncertainty about whether that threat is present. The organization that hunts for a threat and finds nothing knows something it did not know before: that the threat, at least as hypothesized, is not present, which is valuable knowledge even though it is not a found adversary. The empty hunt thus produces knowledge, reducing the uncertainty about the threats, which is value even without a found adversary. And the empty hunt may produce detection too — the hunt that tests for a threat and finds nothing may still build detection for that threat, so that if the threat appears in the future, it is caught, converting the empty hunt into future detection. More deeply, the empty hunt is part of the proper practice of a discipline in which most hunts, in a well-defended organization, should find nothing. If an organization's hunts frequently found adversaries, it would mean the organization was frequently breached, which would reflect poorly on its prevention and detection; in a well-defended organization, most hunts should find nothing, because most of the time no adversary is present, and the hunts confirm this. The empty hunt is thus the expected and desirable outcome in a well-defended organization, confirming the absence of the hypothesized threat, and a hunting program in which most hunts find nothing is not failing but functioning properly in a well-defended organization. Understanding this is important for the hunters' morale — so they do not feel they are failing when their hunts find nothing, which is the expected outcome — and for the proper practice of the discipline — so the hunting is valued for the knowledge and assurance it produces, not only for the adversaries it occasionally finds. The empty hunt confirms the absence of the threat, produces knowledge and assurance, and is the expected outcome in a well-defended organization, which makes it not a failure but a proper and valuable part of the hunting that confirms the defense is holding. This learning closes the loop, and the hunter proceeds to the next hypothesis, beginning the process again, hunt after hunt, each contributing to the defense through its outcome and its learning. This process — hypothesis, search, outcome, learning, repeated — is the shape of hunting, and understanding it clarifies that hunting is a disciplined, repeated process of proactive, hypothesis-driven search, not a one-time activity or an aimless hunt but a continuing practice of searching for the undetected and learning from the search. With hunting defined, the booklet turns to its first requirement: the data to hunt in, without which there is nothing to search. Chapter 3: The Data to Hunt In A hunt searches data, and without data there is nothing to hunt in. This simple fact has a profound consequence: the quality of hunting is bounded by the quality of the data available to hunt in, and an organization that wants to hunt must first ensure it has the data that hunting requires. The hunter searching for an adversary searches the data the environment produces — the records of what happened, the telemetry of activity, the logs of events — and can find only what the data reveals. If the data does not capture the adversary's activity, the hunt cannot find the adversary, however skilled the hunter; if the data captures the activity richly, the hunt can find the adversary, given a skilled hunter. The data is the foundation of hunting, and this chapter is about it: what data hunting requires, why it matters so much, and how the data determines what can be hunted. Visibility is the precondition The fundamental principle is that you can only hunt for what you can see, and what you can see is determined by the data you collect. The adversary's activity leaves traces — in the records of what processes ran, what network connections were made, what files were accessed, what events occurred — and the hunter finds the adversary by finding these traces in the data. But the traces are in the data only if the data captures them: if the environment records the activity that the adversary's traces are in, the hunter can find the traces; if it does not, the traces are not in the data, and the hunter cannot find them. The hunter's visibility into the adversary's activity is thus determined by the data collected — the hunter sees what the data captures and is blind to what it does not — and the data is the precondition of hunting, determining what can be seen and therefore what can be hunted. This principle has a sharp implication: the gaps in the data are the blind spots of the hunt. Wherever the data does not capture activity, the hunter is blind, unable to find an adversary operating in that blind spot, because the adversary's traces there are not in the data. An adversary who operates in the organization's data blind spots — the activity the data does not capture — is invisible to the hunt, which cannot find traces that are not in the data. This means the organization's data gaps are exactly where an adversary can hide from the hunt, operating in the activity the data does not capture, invisible because the hunt can search only the data, and the data does not capture the blind-spot activity. Closing the data gaps — collecting the data that captures the activity — is therefore essential to hunting, because the gaps are the blind spots, and the adversary hides in the blind spots. The practical upshot is that building the data foundation is a precondition of hunting, and often the first substantial work an organization must do to hunt. An organization that wants to hunt but lacks the data to hunt in must first collect the data — ensuring the environment captures the activity the hunt will search, closing the blind spots where an adversary could hide. This data foundation is the precondition, and building it is foundational work, because without the data there is nothing to hunt in, and the hunt's reach is bounded by the data's reach. The organization that builds a rich data foundation can hunt richly, seeing the adversary's activity across the environment; the organization that lacks the data can hunt only poorly, blind wherever the data does not reach. The data foundation determines the hunt's reach, and building it is the precondition of hunting well. What data hunting needs Hunting needs data that captures the activity an adversary engages in, and understanding the kinds of data that capture adversary activity clarifies what the data foundation must include. The adversary, operating in the environment, engages in various activities — running processes, making network connections, accessing files, changing the system, authenticating, moving through the environment — and each of these activities can leave traces in data, if the data captures it. The data foundation for hunting must capture these activities, so that the adversary's traces are in the data for the hunt to find. Table 1. Key data sources for threat hunting and what they reveal. Data source What it captures What it reveals about adversaries Endpoint activity What happens on individual systems — processes, files, actions Much adversary activity happens on endpoints; rich endpoint data is central Network activity Connections and communications across the network Adversary communication, movement, and exfiltration Authentication records Who authenticated, where, and how Adversary use of credentials, lateral movement System and event logs Events the systems record about their operation Many adversary actions appear in system events Application and service logs Activity of applications and services Adversary interaction with applications Among these, endpoint data is often the richest and most important for hunting, because much adversary activity happens on the endpoints — the individual systems where the adversary runs their tools, accesses data, and operates. Rich endpoint data, capturing what happens on the systems in detail, reveals much of the adversary's activity, which is why endpoint visibility is so central to hunting: the adversary operating on the endpoints leaves traces in rich endpoint data, which the hunter can find. The endpoint detection and response tools that provide rich endpoint telemetry are therefore central to the data foundation, capturing the detailed endpoint activity that much hunting searches. Network data is also important, capturing the adversary's communication, movement, and exfiltration across the network — the connections the adversary makes, the communication with their infrastructure, the movement between systems, the data they exfiltrate. This network activity, captured in network data, reveals a dimension of the adversary's operation that complements the endpoint data, and together the endpoint and network data capture much of what the adversary does. Authentication records, capturing the use of credentials, reveal the adversary's use of stolen credentials and their movement through the environment, which is central to many attacks. And the various logs — system events, application activity — capture further dimensions of the adversary's activity, each adding to the data foundation's reach. Together, these data sources, richly collected, capture the breadth of adversary activity, giving the hunt the visibility it needs to find the adversary across the dimensions of their operation. The blind spot that hides the adversary To appreciate why data gaps matter so much, consider how a data gap can hide an adversary entirely from a hunt that would otherwise find them, because the concrete consequence of a gap is an adversary who operates invisibly in the blind spot. Suppose an organization hunts well — skilled hunters, good hypotheses, effective searching — but has a gap in its data, some activity the data does not capture. An adversary who operates in that gap, using the activity the data does not capture, is invisible to the hunt, however well the hunt is conducted, because the hunt searches the data, and the adversary's traces, being in the gap, are not in the data. The hunters, searching the data, find no sign of this adversary, not because the adversary is absent but because the adversary's activity is in the data gap, not captured, not searchable. The hunt that would find an adversary operating in the captured data finds nothing of an adversary operating in the gap, because the gap's activity is not in the data to be found. The adversary, operating in the blind spot, is invisible to even the best hunt, protected not by evading the hunters' skill but by operating where the data does not reach, in the gap the hunt cannot search. This is how a data gap hides an adversary: the adversary operates in the gap, the gap's activity is not in the data, the hunt searches the data, and the hunt finds nothing, the adversary invisible in the blind spot. This illustrates why closing the data gaps is so important, and why the data foundation bounds the hunt. The best hunters, with the best method, are blind in the data gaps, unable to find an adversary operating where the data does not reach. The hunt's reach is bounded by the data's reach, and the data gaps are the blind spots where an adversary can operate invisibly, beyond even the best hunt. The organization that closes its data gaps — capturing the activity across the environment — denies the adversary the blind spots, so the adversary has nowhere to operate invisibly, caught by the hunt wherever they operate because the data reaches everywhere. The organization that leaves data gaps leaves the adversary blind spots, where the adversary can operate invisibly, beyond the hunt that cannot search the gap. This is why the data foundation is so important and why closing the gaps matters: the gaps are the blind spots, the blind spots hide the adversary, and the hunt, however good, is blind in them. The data foundation determines where the hunt can see, and the gaps determine where the adversary can hide, so closing the gaps — extending the data's reach — is how the organization denies the adversary the blind spots and extends the hunt's reach to everywhere the adversary might operate. The challenge of volume A difficulty that accompanies the data foundation is volume — the data that captures adversary activity richly is voluminous, and the volume poses challenges of storage, processing, and searching that the organization must address. Rich data capturing the detailed activity across a large environment is a great deal of data, and collecting, storing, and searching it is a substantial undertaking, requiring the capacity to handle the volume. The organization that wants rich data for hunting must handle the volume that rich data entails, which is a real challenge, requiring investment in the capacity to collect, store, and search the voluminous data. The volume challenge creates a tension between the richness of the data, which hunting wants, and the cost of handling it, which constrains how much can be collected. Richer data captures more adversary activity, giving the hunt more to find, but richer data is more voluminous, costing more to collect, store, and search. The organization must balance the richness it wants against the cost it can bear, collecting data rich enough to capture the adversary activity the hunt needs while handling the volume the richness entails. This balance is a real consideration in building the data foundation, and it is resolved by collecting the data that matters most for hunting — the data that captures the adversary activity the hunt most needs to see — richly, while being more selective about data that matters less, so that the voluminous rich data is focused where it most serves the hunt. Knowing your own normal A dimension of the data foundation that deserves emphasis is that hunting depends not only on capturing the data but on understanding what is normal in it, because much hunting works by finding the abnormal against the background of the normal, and finding the abnormal requires knowing the normal. The adversary's activity, in much hunting, is found as an anomaly — something that stands out against the background of normal activity, abnormal in a way that reveals the adversary. But finding the abnormal requires knowing the normal, because the abnormal is defined against the normal, and without knowing what is normal, the hunter cannot recognize the abnormal that the adversary's activity represents. This means that the hunter must understand the organization's normal activity — what the normal patterns are, what the usual behavior looks like, what is expected — so that the abnormal, the adversary's activity standing out against the normal, can be recognized. The hunter who knows the normal can recognize the abnormal, finding the adversary's activity as a deviation from the normal; the hunter who does not know the normal cannot recognize the abnormal, unable to tell the adversary's activity from the normal activity it hides among. Knowing the organization's normal is thus a foundation of hunting, part of what the hunter must understand to find the adversary, because the adversary is often found as an anomaly against the normal, and finding the anomaly requires knowing the normal. Building this understanding of the normal is part of building the data foundation and the hunting capability. The hunter develops an understanding of the organization's normal activity — through studying the data, through experience with the environment, through the knowledge of what is expected — so that the hunter can recognize the abnormal against the known normal. This understanding of the normal is a form of knowledge the hunter builds about the specific environment, which makes the hunter more effective in that environment, able to recognize the abnormal that reveals the adversary. It is why hunters become more effective in an environment over time, as they build the understanding of its normal that lets them recognize the abnormal — and why understanding the organization's own environment deeply is part of the hunting capability, enabling the recognition of the abnormal against the known normal that much hunting requires. The data captures the activity; the understanding of the normal lets the hunter recognize the abnormal in it; and both are needed for the hunting that finds the adversary as an anomaly against the normal background that the hunter must know. The volume challenge also drives the need for the tools that handle the data — the platforms that collect, store, and search the voluminous data, which a later chapter addresses. The data foundation is not just the data but the capacity to handle it, and the tools that provide this capacity are part of the foundation, enabling the collection, storage, and searching of the voluminous data that hunting requires. The organization that builds the data foundation builds both the data collection and the capacity to handle the data, so that the voluminous rich data is not just collected but usable, searchable by the hunt that needs to search it. There is also the matter of retention — how long the data is kept — which matters because an adversary may have been present longer than the data reaches back, and finding them may require data from before the retention window. Adversaries often operate for a long time before being found, and finding the full extent of their activity may require data reaching back to when they first entered, which may be longer ago than the data is retained. If the data is retained only for a short window, the hunt can see only the recent activity, blind to the adversary's earlier activity that fell outside the retention window, unable to find the full extent of a long-present adversary. The retention window thus bounds how far back the hunt can see, and a short window blinds the hunt to the earlier activity of a long-present adversary. Balancing retention against the cost of keeping voluminous data long is part of building the data foundation, and the organization must retain the data long enough to find the adversaries who may have been present for a while, which argues for retention windows long enough to reach back to when a long-present adversary might have entered, balanced against the cost of the long retention of voluminous data. With the data foundation established — the rich data capturing adversary activity, and the capacity to handle its volume — the hunter has something to hunt in, and the booklet turns to how the hunter actually hunts: forming and testing the hypotheses that direct the search through the data, which is where the hunt's method lives. Hashtags: #ThreatHunting #ProactiveCyberDefense #IncidentResponse #AssumeBreach #ProactiveSecurity #HypothesisDrivenHunting #UndetectedThreats #AdversaryDetection #BehaviorBasedDetection #ThreatHypotheses #SecurityTelemetry #EndpointTelemetry #NetworkTelemetry #AuthenticationLogs #SystemEventLogs #ApplicationLogs #DetectionEngineering #ThreatInvestigation #SecurityOperations #AdversaryBehavior #DataVisibility #SecurityBlindSpots #HuntingMaturity #DetectionImprovement #FutureOfThreatHunting

Download the Book (PDF): Introduction For about sixty years, the people who designed software could rely on one quiet promise from the machines they were designing for. Press the same button with the same data and you get the same result. A spreadsheet that adds a column today will add it identically tomorrow. A search box that returns ten results for a query will return the same ten, in the same order, until the index changes. Almost every habit of interface design rests on that promise. We write error messages because we know which errors can occur. We draw progress bars because we know how many steps remain. We test a flow once, fix it, and trust it to stay fixed. Generative models break the promise. Ask a large language model the same question twice and you may get two different answers, both fluent, one of them wrong. Ask an image model for "a red bicycle against a brick wall" and you receive a picture nobody specified in detail, made of choices nobody made deliberately. The output is not retrieved from anywhere. It is composed, on the spot, by a statistical process that samples from a distribution of plausible continuations. That is what makes these systems astonishing, and it is also what makes them so strange to design for. This booklet is about that strangeness and what to do about it. Its argument is simple to state and demanding to practise. When the output of software can no longer be specified in advance, the interface stops being a window onto a predictable machine and becomes the main instrument by which a person decides how far to rely on an unpredictable one. The designer's job shifts accordingly. It is no longer chiefly to arrange controls so that the right outcome follows from the right action. It is to help people express what they want when they do not yet know how to ask, to judge output whose quality varies from one attempt to the next, to catch and recover from errors that look exactly like successes, and to feed what they learn back into the system. In short, the job is to design for calibrated trust: reliance that rises and falls with the system's actual reliability on the task in hand. Why this is a design problem It is tempting to treat the shortcomings of generative AI as purely technical problems that better models will solve. Models have improved quickly and will keep improving. But two things will not change soon. The first is that these systems are probabilistic by construction; even very good ones will sometimes produce confident, well-formed, false output. The second is that the people using them are human, with all the usual tendencies to over-trust fluent prose, to anchor on the first suggestion, and to skip verification when they are busy. The evidence that these tendencies matter is now substantial. In a field experiment with 758 consultants at Boston Consulting Group, published in 2023 by Fabrizio Dell'Acqua and colleagues, people using GPT-4 on tasks the model handled well completed 12.2 per cent more tasks, finished 25.1 per cent faster and produced work rated more than 40 per cent higher in quality. On a task deliberately chosen to fall outside the model's competence, consultants with AI access were 19 percentage points less likely to reach the correct answer than those working without it. The tool did not merely fail to help; it pulled capable professionals away from the right answer. The researchers called the boundary between those two kinds of task a "jagged technological frontier", jagged because tasks of similar apparent difficulty can sit on opposite sides of it, and nothing about the model's tone tells you which side you are on. That last point is the heart of the matter. A generative system's confidence and its correctness are only loosely connected, and the interface is where the gap either gets exposed or gets papered over. A chat window that renders every answer in the same calm typography, with no indication of source or certainty, papers over it. An interface that shows where a claim came from, makes it easy to check, and frames the system's role honestly exposes it. Both are design choices. What this booklet covers, and what it leaves out The chapters move roughly in the order a person meets a generative product. The first explains what non-determinism actually does to the assumptions of interface design, and why older frameworks still help when read correctly. The second deals with the blank prompt box, the most common and in many ways the least helpful interface ever shipped to mass audiences, and with the alternatives that help people say what they mean. The third looks beyond the chat window at the range of interaction patterns now in use, from inline completion to shared canvases to agents that act on a person's behalf, and how to choose among them. The middle of the book turns to error. Chapter Four treats hallucination as a permanent property of the medium rather than a bug awaiting a patch, and asks how products should set expectations about it. Chapter Five looks at the research on trust and reliance: what actually helps people rely on AI when it is right and doubt it when it is wrong, and what merely makes them feel better. Chapter Six turns from trust to verification and recovery, the practical machinery of checking, editing, undoing and constraining. The last two chapters close the loop. Chapter Seven examines feedback, the signals products collect from users to improve models, and the surprising ways those signals can backfire, including a well-documented case in 2025 when optimising for user approval made a widely used model flatter its users into trouble. Chapter Eight addresses measurement: how teams can know whether a product whose output never repeats is getting better or worse. Some things are deliberately left out. This is not a technical manual for training models, nor a guide to any single vendor's tools, nor a survey of AI ethics in general, though ethical questions run through every chapter because they are inseparable from design decisions. Nor is it a catalogue of interface widgets. The tools change every few months. The underlying problems, how people form intentions, how they judge output, how they come to trust and distrust machines, change much more slowly, and they are what a designer needs to understand. A word on evidence The field is young and noisy. Many claims about AI interfaces come from vendor blogs, conference talks or confident social media threads, and some of the most repeated ones have never been tested. Where this booklet makes an empirical claim, it rests on published research, a public record such as a court ruling, or a company's own account of what happened. Where the evidence is thin or contested, the text says so. The aim is not to pretend the field has settled answers it lacks, but to give designers, product managers and anyone else building these systems a clear way of thinking about problems that will outlast any particular model. One finding deserves mention at the start because it frames everything that follows. In a randomised controlled trial published by the research group METR in July 2025, sixteen experienced open-source developers worked on 246 real issues in their own repositories, with and without AI tools. Before starting, they forecast that AI would speed them up by 24 per cent. Afterwards, they estimated it had sped them up by about 20 per cent. Measured against the clock, they had in fact taken 19 per cent longer with AI than without it. The researchers were careful to describe this as a snapshot of early 2025 tools on a particular kind of work, and later results may differ. But the gap between how the work felt and what actually happened is exactly the gap that interface design for generative AI has to take seriously. People's sense of how well a generative system is serving them is not a reliable instrument. Good design gives them a better one. Chapter 1: The Broken Contract Every interface makes an implicit agreement with the person using it. It says, in effect: if you do this, that will happen. A light switch keeps the agreement perfectly. A word processor keeps it almost perfectly; the occasional crash is remembered precisely because it violates the norm. Users build their competence on these agreements. They learn which action produces which result, and the learning sticks because the result does not move. Generative AI products keep a different and much weaker agreement. They say: if you do this, something in roughly this region will happen, and it will usually be useful, and occasionally it will be wrong in ways that look identical to being right. Understanding precisely how this agreement differs from the old one is the foundation for everything else in this booklet. Where the variability comes from It helps to be concrete about why a language model gives different answers to the same question, because "the AI is unpredictable" is too vague to design against. There are at least four distinct sources of variation, and each has different consequences for the interface. The first is sampling. A language model does not compute a single answer. At each step it produces a probability distribution over possible next tokens, the word fragments from which text is built, and the system then picks one. If it always picked the most probable token, output would be more repeatable, though often duller and prone to loops. Most products instead sample with some randomness, controlled by a parameter usually called temperature. Higher temperature spreads the choice across more candidates and yields more varied text. This is intentional variability: the product chooses it because varied output is more useful for brainstorming, writing and image generation. Even at a temperature of zero, many commercial systems do not guarantee bit-identical output across calls, for reasons that include the way computations are batched on shared hardware. The second source is context. The output depends on everything in the model's input: the user's words, the conversation so far, any documents retrieved from a search, and the hidden instructions the product team has written, usually called the system prompt. Small changes in any of these can produce large changes in output. A user who rephrases a question slightly, or who asks it later in a long conversation, is effectively asking a different question. Research by Nelson Liu and colleagues in 2023 showed that models handling long inputs were measurably better at using information placed at the beginning or end of the context than in the middle, an effect the authors called "lost in the middle". The practical upshot is that what the user sees as the same request may reach the model as a different one. The third source is the model itself changing. Vendors update models, sometimes silently and sometimes with fanfare. A prompt that worked well last month may behave differently today, not because the user did anything but because the system underneath was replaced. For a designer this is a peculiar situation: the product's behaviour can shift without a single line of the product's own code changing. The fourth source is the task. Generative systems are uneven. They may write excellent code in one language and poor code in another, summarise news articles well and legal contracts badly, answer questions about popular topics accurately and invent details about obscure ones. This is the jagged frontier described in the introduction, and it means that the variability a user experiences is not a fixed property of "the AI" but a function of what they happen to be asking it to do. These four sources compound. A user who gets a brilliant answer on Monday and a poor one on Tuesday cannot easily tell whether the difference came from randomness, from how they phrased the question, from a model update, or from the fact that Tuesday's question sat on the wrong side of the frontier. Neither, often, can the product team. That opacity is the real design problem. The old assumptions, one by one Most of what designers know about making software usable rests on assumptions that generative systems quietly violate. It is worth naming them, because a team that does not notice which assumptions have failed will keep applying techniques that no longer work. Consider repeatability. Traditional usability testing assumes that if five participants struggle with a flow, the flow is at fault and a fix will help the next five. With generative output, two participants may see quite different responses to the same action, and a session that went well may have gone well partly by luck. Consider error states. Conventional software has a finite set of failure modes, each of which can be anticipated and given a message. A generative system's most important failure mode, producing plausible but wrong output, generates no error at all from the system's point of view. There is nothing to catch and nothing to display. Consider specification. In ordinary product development, a designer can mock up exactly what a screen will show. With generative features, the core content of the screen is unknown until runtime. Designers end up drawing boxes labelled "AI response here" and discovering only in production what actually fills them, including the cases where the response is ten times longer than the box, written in the wrong language, or politely refuses to answer. Consider learnability. People learn conventional interfaces by building a mental model of cause and effect. With generative systems, the causal connection between input and output is loose and partly hidden, so people's mental models tend to be either too generous (the system understands me) or too vague (it is magic). Neither supports good judgment. Table 1 sets out these contrasts side by side, because the pattern across them is the point: each old assumption has a counterpart that changes what the designer must do. Table 1. How generative systems change the working assumptions of interface design. Assumption Conventional software Generative system Design consequence Repeatability Same input, same output Same input, varied output Test across many samples, not one Errors Finite, detectable, messageable Fluent, silent, look like success Make verification part of the flow Specification Screen content known at design time Content composed at runtime Design for ranges and extremes of output Capability Uniform across features Uneven across tasks and topics Signal scope; route around weak areas Change Behaviour changes only with releases Model updates shift behaviour Monitor output in production continuously Mental model Cause and effect learnable Causation loose and hidden Expose sources, reasoning, and limits One feature, four kinds of surprise It helps to see these sources of variation at work in a single, ordinary feature. Imagine a software company that adds an assistant to its help centre. Customers type questions about billing, and the assistant answers using the company's documentation, which it retrieves and passes to a language model along with a system prompt instructing it to be concise and friendly. On launch day, a customer asks whether they can get a refund on an annual plan after thirty days. The assistant answers correctly: refunds are available within fourteen days, after which the plan can be cancelled at renewal. An hour later, another customer asks the same question in slightly different words, "I bought the yearly plan last month, can I get my money back?", and receives an answer that mentions the fourteen-day window but adds, unprompted, that exceptions can be made in special circumstances. Nothing in the documentation says this. The sampling process happened to wander toward a sentence that is common in refund policies generally. That is the first source of variation. A week later, the documentation team publishes a new help article about refunds for business customers, with different terms. Now the retrieval step sometimes returns that article instead of the consumer one, depending on the exact phrasing of the question, and the assistant confidently quotes business terms to individual customers. No one changed the assistant. The context changed underneath it. That is the second source. A month later, the model vendor releases an update, and the company's integration switches to it automatically. The new model is better at many things and slightly more verbose. Answers that used to be two sentences are now five, and the extra sentences include friendly suggestions to contact support that send a wave of unnecessary tickets to the human team. That is the third source. Meanwhile, the assistant handles billing questions well but is noticeably worse at questions about tax, which require reasoning about the customer's country and the interaction between several policies. Customers who ask about tax get fluent answers that are wrong about a third of the time, according to a later audit. The assistant sounds exactly as confident on tax as on billing. That is the fourth source, the jagged frontier, playing out inside a single product. None of these problems would show up in a conventional pre-launch test of a dozen questions, and none of them produces an error message. Each was eventually found through some combination of customer complaints, support ticket volumes and someone on the team happening to read a sample of conversations. The example is invented, but every element of it is drawn from patterns that teams deploying such assistants commonly report, and several echo real cases discussed later in this booklet. The point is that a team designing this feature needed to anticipate all four kinds of surprise, and the design responses differ for each: constraining generation to the retrieved text for the first, managing and labelling sources for the second, pinning model versions and testing before switching for the third, and scoping the assistant away from tax questions, or routing them to a human, for the fourth. Old frameworks that still work It would be a mistake to conclude that everything known about interaction design is obsolete. Some of the oldest frameworks turn out to describe the new problems unusually well, provided they are read with care. Don Norman's account of the two gulfs, set out in The Design of Everyday Things, is the most useful. The gulf of execution is the distance between what a person wants to do and the actions the system makes available. The gulf of evaluation is the distance between what the system has done and the person's ability to tell whether it matches their goal. Conventional design spends most of its effort narrowing the gulf of execution: clear buttons, sensible menus, visible affordances. Generative interfaces invert the emphasis. Execution looks almost trivially easy: type what you want in plain language. In practice it is harder than it looks, a problem the next chapter takes up, because people do not know what the system can do or how to phrase a request that gets it. Researchers at Stanford University and the University of Michigan have argued that there is in fact a third gulf before execution even begins. Hari Subramonyam and colleagues, in a 2024 CHI paper, called it the gulf of envisioning: the difficulty of forming an intention specific enough to act on when you do not know what the system is capable of producing. But the truly wide gulf is evaluation. A conventional system that shows "file saved" has done what it said. A generative system that shows a well-formatted summary of a forty-page report has done something, but whether that something faithfully represents the report is exactly what the user cannot easily judge, since the point of asking for a summary was to avoid reading the report. Much of this booklet is, in effect, about narrowing the gulf of evaluation. The second framework that survives is the literature on human trust in automation, which predates generative AI by decades and was built on aviation, process control and military systems. Its central concepts, overreliance and underreliance, calibration and complacency, apply directly. Raja Parasuraman and Victor Riley, writing in 1997, distinguished between the use of automation, its misuse through overreliance, its disuse through neglect, and its abuse when designers automate without regard to the human consequences. John Lee and Katrina See's 2004 review argued that the goal is not maximal trust but appropriate trust, trust that matches the system's true capabilities. Chapter Five draws heavily on this work, because the problems it describes, a pilot who stops monitoring an autopilot, an operator who switches off an alarm that cries wolf, have exact analogues in a knowledge worker who stops checking an assistant's citations. Design principles written for the new medium Several research groups and companies have tried to codify what good design for AI looks like. Two efforts are especially worth knowing, one from before the generative wave and one from inside it. In 2019, Saleema Amershi and colleagues at Microsoft published eighteen guidelines for human-AI interaction at the CHI conference, distilled from more than two decades of proposals and tested against real products. They are organised by when they apply: initially, during interaction, when the system is wrong, and over time. Among them are making clear what the system can do, making clear how well it can do it, supporting efficient correction, making clear why the system did what it did, learning from user behaviour, and notifying users about changes. The guidelines were written mainly with recommendation and prediction systems in mind, but almost every one of them applies with more force to generative products, because generative systems fail more variously and more invisibly. In 2024, Justin Weisz and colleagues at IBM Research published six principles specifically for generative AI applications, also at CHI. Three of them concern the user's relationship to the system: design for mental models, design for appropriate trust and reliance, and design responsibly. Three concern the nature of the output: design for generative variability, design for co-creation, and design for imperfection. The phrase "design for generative variability" is worth dwelling on, because it reframes what most teams experience as a defect. Variability is not only a risk to be contained; it is often the product. A person exploring logo concepts wants variety. A person drafting an email wants options. The design question is when variability helps, when it harms, and how to let the user control it. That framing matters for a practical reason. Teams that treat non-determinism purely as a reliability problem tend to try to eliminate it, lowering temperature, constraining output, adding guardrails until the system is predictable and dull. Teams that treat it purely as a creative asset tend to ignore its costs, shipping systems that give different answers to the same factual question. The better approach is to decide, feature by feature, which kind of task is in play. When a user asks for the capital of a country or the balance of an account, variation is pure cost and the design should suppress it, ideally by retrieving the answer from a reliable source rather than generating it. When a user asks for twenty possible names for a product, variation is the point and the design should expose it, perhaps by showing several options at once rather than one. The shape of the new job If the old contract was "do this and that happens", the new one has to be negotiated afresh in each product. A useful way to think about it is as a set of commitments the interface makes on the system's behalf, honest commitments that the system can actually keep. The interface can commit to being clear about what the system is for and where it is weak. It can commit to showing its sources where it has them and to saying so where it does not. It can commit to making its output easy to check, easy to change and easy to undo. It can commit to keeping the person in charge of anything consequential. And it can commit to learning from what people tell it, while being honest about how and whether that learning happens. None of these commitments promises correct output. That promise is not available. What they promise instead is that the person using the system will be in a position to judge it, which is the only promise a probabilistic tool can keep. There is a revealing contrast here with the way generative products have often been marketed. Launch announcements tend to emphasise capability: what the model can do at its best. Interfaces built in the same spirit present the model as an oracle, a single answer delivered with authority. Interfaces built for calibrated trust present it more like a capable but fallible colleague: someone whose drafts are worth having and whose claims are worth checking, and whose strengths and blind spots you learn over time. The second framing is less exciting in a demo and much more durable in daily use. The rest of this booklet is about how to build that second kind of interface. It begins where most users begin: in front of an empty box, wondering what to type. Chapter 2: The Tyranny of the Blank Box The most widely used interface for generative AI is also one of the oldest ideas in computing: a text field and a blinking cursor. When ChatGPT launched in November 2022, its interface was barely more elaborate than a command line from the 1970s, and the products that followed largely copied it. The appeal is obvious. A blank box promises that you can ask for anything, in your own words, with no menus to learn. It is the purest possible expression of the idea that the machine will finally understand us. The trouble is that the promise is only half true. The machine will accept anything, but it will not respond equally well to everything, and the box tells the user nothing about the difference. A blank prompt field is maximally flexible and minimally informative. It puts the entire burden of figuring out what is possible, and how to ask for it, on the person least equipped to carry it. A new paradigm with an old problem In 2023 Jakob Nielsen argued that generative AI introduced the first genuinely new user interface paradigm in about sixty years. He described the history of computing interfaces as passing through two earlier stages: batch processing, where users submitted a complete specification and waited for results, and command-based interaction, which includes both command lines and graphical interfaces, where users issue a sequence of commands and see the effect of each. The new paradigm he called intent-based outcome specification. The user describes the result they want, and the computer works out how to produce it. The framing is useful because it clarifies what has been gained and what has been lost. In a graphical interface, the user is in control of each step. They choose a font, see it applied, choose another. The interface constrains them, but the constraints are also guidance: the menu shows you what is possible. In an intent-based interface, the user gives up step-by-step control in exchange for not having to know the steps. That is a good trade when the system understands the intent and produces the right outcome. It is a bad trade when it does not, because the user now has no obvious way to steer. Nielsen also pointed out a problem that tends to get lost in enthusiasm about natural language: writing a clear description of what you want is hard. It requires knowing what you want, which is often not the case at the start of a creative or analytical task, and it requires the ability to put that want into precise prose. He called this the articulation barrier. Many capable people are not fluent writers, and even fluent writers struggle to specify an image, a piece of code or a tone of voice in words. A blank box rewards people who already write well and already know what the system can do. It quietly penalises everyone else. What people actually do with a prompt box The best early evidence on how ordinary people approach prompting came from a 2023 CHI paper by J. D. Zamfirescu-Pereira, Richmond Wong, Bjoern Hartmann and Qian Yang, titled "Why Johnny Can't Prompt". The researchers asked people without AI expertise to design prompts for a chatbot, for instance one that would walk a user through a cooking recipe, and watched how they went about it. The findings are instructive for anyone designing a prompt interface. Participants approached prompting opportunistically rather than systematically, trying something, seeing what happened and reacting, rather than forming hypotheses and testing them. They tended to overgeneralise from single examples: if a prompt worked once they assumed it would always work, and if it failed once they assumed the approach was hopeless. They brought expectations from human conversation, expecting the model to follow instructions the way a person would, and were confused when it did not. Some found that phrasing instructions politely or indirectly worked differently from phrasing them as commands, without being able to predict which would succeed. None of this reflects a lack of intelligence. It reflects the absence of feedback that would let people build an accurate mental model. When a prompt fails, the system does not say why. When it succeeds, it does not say which part of the prompt mattered. The person is left to infer the rules of a complicated, invisible system from a handful of noisy observations, and people are not good at that kind of inference. The design implication is that prompting, left to itself, is a skill most users will never acquire, and a product whose usefulness depends on it will serve a narrow audience well and everyone else poorly. The job is either to teach the skill efficiently or, more often, to make it unnecessary. Scaffolding the request The most common response to the blank box problem is to put something in it, or around it. There is now a recognisable toolkit of techniques, each of which narrows the gulf of envisioning in a different way. The simplest is the suggested prompt: a few clickable examples displayed when the box is empty. These do more work than they appear to. They show the range of things the system can do, they demonstrate a level of specificity that tends to produce good results, and they give hesitant users a zero-effort way to begin. Their weakness is that they are static. A list of four generic suggestions on a general-purpose assistant tells users little about whether their own particular task is a good fit. A stronger version is the template: a structured prompt with blanks for the user to fill in. A marketing tool might offer "Write a product description for [product] aimed at [audience] in a [tone] tone, under [length] words." Templates encode expertise about what makes a good request. Their limitation is that they suit repeatable tasks and become awkward for anything unusual. Further along the spectrum is the structured input form, where the interface collects the elements of a good request through ordinary controls, dropdowns, sliders, checkboxes, and composes the actual prompt behind the scenes. The user never sees a prompt at all. Many of the most successful generative features in business software work this way: a button labelled "Summarise this thread", a menu offering "Make shorter", "Make more formal" or "Translate", a slider controlling how creative an image should be. These features are less flexible than a blank box, but they are more discoverable, more predictable and far easier to test, because the space of possible requests is bounded. Another approach puts the model to work on the request itself. When OpenAI integrated its DALL-E 3 image model into ChatGPT in 2023, the system took a user's brief description and expanded it into a much more detailed prompt before generating the image; the company's technical report on the model described this rewriting as part of its design. The approach narrows the articulation barrier dramatically: the user writes "a cosy reading nook", the system writes three sentences about lighting, furniture and colour. The cost is a loss of transparency and control. The user's words are no longer what the model sees, and if the rewritten prompt introduces something unwanted, the user may not know why. Products that rewrite prompts should show the rewritten version and let the user edit it. A related pattern is the clarifying question. Instead of guessing at an ambiguous request, the system asks. "Do you want a summary for an executive audience or a technical one?" This mirrors what a good human assistant does, and it can be valuable for long or expensive tasks, such as a research agent that will spend many minutes gathering sources. It can also become an irritation. A system that asks three questions before answering a simple request feels obstructive. The design judgment is about cost: ask when a wrong guess would waste significant time or money, and otherwise make a sensible assumption, state it, and let the user correct it. Finally, there is the suggested follow-up. After producing a response, many assistants now offer two or three next steps the user might take: "Make this more concise", "Add examples", "Turn this into a table". These help users discover capabilities in context, at the moment they are relevant, which is far more effective than front-loading a tutorial. Moving the intent out of language The deeper response to the blank box is to recognise that language is only one way of expressing intent, and often not the best one. People can point, select, drag, sketch and choose. Many of the most effective generative interfaces combine language with these older forms of direct manipulation. Consider text editing. A user who wants a single paragraph rewritten could type "please rewrite the third paragraph of the document to be more concise". Or they could select the paragraph and click "shorten". The second is faster, less ambiguous and impossible to misinterpret as referring to a different paragraph. Selection-based editing, where the user highlights part of a document and then asks for a change to just that part, has become a standard pattern in writing tools for exactly this reason. Image tools offer the clearest examples. Early text-to-image systems required users to describe every change in words, which made iterative refinement nearly impossible: changing the colour of a single object meant rewriting the whole prompt and hoping the rest of the image survived. Inpainting, where the user paints a mask over part of an image and describes what should replace it, transformed the experience. So did features that let users generate variations of an image they liked, upscale one of several candidates, or extend the canvas beyond its original borders. In each case, the user expresses intent through a combination of pointing and describing, and the pointing removes most of the ambiguity. Reference-based input is another powerful technique. Rather than describing a style in words, a user supplies an example: an image whose style should be matched, a document whose tone should be imitated, a spreadsheet whose format should be followed. Examples carry a great deal of information that is hard to articulate, and they sidestep the articulation barrier almost entirely. Parameters deserve a mention too, though they are easy to overuse. Exposing a control for length, formality or creativity gives users a way to steer without rewriting their request. The risk is that the parameters mean nothing precise. A "creativity" slider that maps to a sampling temperature does not reliably produce more creative output, only more random output, and users quickly learn that the control does not do what its label promises. A parameter should be exposed only when moving it produces a change the user can perceive and predict. Who the blank box leaves out The articulation barrier falls hardest on particular groups, and a designer should know who they are. People who write with difficulty, whether because of dyslexia, limited formal education or simply lack of practice, face a steep cost in composing detailed prompts. People working in a second language may be able to read the output well but struggle to phrase requests with the precision the model rewards. Older users who are less familiar with conversational software may not realise that they can ask follow-up questions or push back on an answer. People using screen readers or other assistive technology may find that long, unstructured responses are hard to navigate. Several design choices help. Voice input lowers the cost of articulation for many users, because speaking a request is easier than writing one, though spoken requests tend to be less structured and the interface may need to confirm its interpretation before acting. Multilingual support matters more than it might seem: models typically perform best in English and somewhat worse in other languages, and a product should be tested in each language it supports rather than assumed to work equally well. Short, structured responses with clear headings are easier to navigate with assistive technology than long blocks of prose. And interfaces that offer concrete options at each step, rather than relying on the user to know what to type, serve everyone who finds open-ended composition difficult. There is also a subtler exclusion. The most effective prompting techniques, giving the model a role, supplying examples, specifying a format, breaking a task into steps, are well known among enthusiasts and nearly unknown among everyone else. A product that works well only for people who have read about prompting has quietly built a skill barrier into its core interaction. The fairer approach is to encode those techniques into the product, in templates, structured inputs, prompt rewriting and system prompts, so that every user benefits from them without having to learn them. The prompts users never see There is another kind of prompt in every generative product, one that users rarely see and designers often neglect. The system prompt is the set of instructions the product team writes to shape the model's behaviour: its persona, its tone, its rules, what it should refuse, how it should format answers. In many products the system prompt is longer than any message a user will ever write, and it influences every response. In practice, system prompts are often written by engineers under deadline, revised by whoever notices a problem, and never reviewed by the people responsible for the product's voice or user experience. That is a mistake. A system prompt is design material in exactly the way interface copy is design material. It determines whether the product sounds warm or brisk, whether it hedges or commits, whether it asks clarifying questions or makes assumptions, whether it uses headers and bullet lists or flowing prose. Each of these is a user experience decision. Treating system prompts as design artefacts has practical consequences. They should be versioned, so that changes can be traced to shifts in behaviour. They should be tested against a set of representative user requests whenever they change, because a small edit intended to fix one problem frequently causes another. And they should be read by the people who understand the users, because an instruction that seems sensible to an engineer, such as "always provide comprehensive answers", may produce responses that are exhausting for a person on a phone. There is also an honesty question. Users form impressions of what the system is and does from how it behaves, and they do not know that much of that behaviour comes from hidden instructions. When the product's personality is warm and attentive, users may infer that the system cares about them. When it refuses certain requests, they may infer moral judgment rather than a policy decision. Designers should consider what users will reasonably infer from behaviour shaped by the system prompt and avoid shaping it in ways that create false impressions. Memory, context and the shrinking prompt A final trend is changing the prompt problem from a different direction. Products increasingly carry information about the user from one session to the next: custom instructions the user writes once, documents uploaded to a project, preferences inferred from past conversations, and in some cases an explicit memory feature that stores facts the user has mentioned. The more the system knows about the context, the less the user needs to put into each request. "Draft a reply" can be enough if the system already knows the email thread, the user's role and their usual tone. This is genuinely helpful, and it moves generative interfaces toward something closer to a knowledgeable assistant than a stranger who must be briefed from scratch. It also raises design questions that have no counterpart in conventional software. Users need to know what the system remembers about them, need to be able to see it, and need to be able to correct or delete it. A memory that silently retains a mistaken belief about the user, that they are a beginner when they are an expert, that they prefer a style they actually dislike, will degrade every subsequent response in ways the user cannot diagnose. And a system that surfaces something the user mentioned months ago, in a context where they did not expect it to be known, can feel invasive even when it is technically helpful. The principle that runs through all of this is that the user should be able to see what the model sees, or at least the parts of it that matter. When the input to the model includes a rewritten prompt, retrieved documents, stored memories and hidden instructions, the user's own words may be a small fraction of it. If the user cannot see the rest, they cannot understand why the output came out as it did, and they cannot steer it effectively. A good prompt interface, in the end, is not one that makes prompting unnecessary. It is one that makes the full request legible, so that the person can recognise when the system has misunderstood and fix it. The blank box, then, is not wrong so much as incomplete. It suits expert users with open-ended needs and serves them well. For everyone else, and for most specific tasks, it is a starting point that needs scaffolding, structure and other channels of intent around it. The next chapter widens the view further, to the range of interaction patterns that have grown up beyond the chat window. Chapter 3: Beyond the Chat Window Chat became the default interface for generative AI partly by accident. The first product to reach a mass audience was a chatbot, and the format was cheap to build, easy to understand and flexible enough to absorb almost any request. Within two years, the chat window had been bolted onto search engines, word processors, spreadsheets, customer service sites, banking apps and car dashboards. In many of those places it did not belong. Conversation is a good interface for some things: open-ended questions, exploratory thinking, tasks where the goal emerges through dialogue. It is a poor interface for many others. Conversations are linear, while most work is not. They scroll away, burying earlier results. They separate the AI's output from the material it concerns, so that a user editing a document must copy text out of a chat panel and paste it back. They encourage a turn-taking rhythm that suits a question-and-answer exchange but fits awkwardly with the way people actually write, code or design. The most interesting work in generative interface design over the past few years has been the search for better patterns. This chapter surveys the main ones and offers a way of choosing among them. A brief lesson from 1999 Before the current wave, the most important thinking about how intelligent systems should share control with people came from Eric Horvitz at Microsoft Research. His 1999 CHI paper, "Principles of Mixed-Initiative User Interfaces", set out a framework that remains strikingly relevant. Horvitz argued that an automated assistant should weigh the expected value of taking an action against the expected cost of being wrong, given its uncertainty about what the user wants. When the system is confident and an error would be cheap, it can act. When it is unsure, it should ask or offer. When it is very unsure, or an error would be costly, it should stay out of the way. The same era produced the most famous counterexample. Microsoft's Office Assistant, the animated paperclip widely known as Clippy, interrupted users with offers of help based on crude guesses about their intentions, and it was so widely disliked that it became shorthand for intrusive software. The lesson was not that assistance is unwelcome. It was that assistance must be calibrated to the user's actual needs and the system's actual confidence, and that interruption has a cost which the system must earn the right to impose. Generative systems are vastly more capable than Clippy, but the cost-benefit logic Horvitz described still governs the choice of interaction pattern. Every pattern below represents a different answer to the questions of when the system should take initiative, how much it should do at once, and how easily the user can accept, change or reject what it produces. Inline completion The quietest pattern is inline completion. As the user types, the system predicts what comes next and displays it in faded text, sometimes called ghost text. A single keystroke accepts the suggestion; continuing to type ignores it. GitHub Copilot popularised the pattern for programming from 2021 onwards, and it has spread to email, documents and search. Inline completion has unusual virtues. It requires no prompt at all, because the context is the work itself. It interrupts minimally, since a suggestion that is ignored costs only a moment's glance. It keeps the user firmly in control: nothing changes unless they accept it. And it operates at a granularity, a line or a few lines, small enough that the user can evaluate each suggestion almost instantly. Early evidence on the pattern was encouraging. In a controlled experiment reported by Sida Peng and colleagues in 2023, developers given access to Copilot completed a task of writing a simple web server in JavaScript 55.8 per cent faster than a control group. A study by Albert Ziegler and colleagues at GitHub, analysing usage data alongside survey responses, found that the rate at which developers accepted suggestions was a better predictor of how productive they felt than more elaborate measures of how much code survived. That second finding is double-edged. It suggests acceptance rate is a convenient proxy for perceived value, but perception and reality can diverge, as the METR study described in the introduction showed with more complex tasks a few years later. The limits of inline completion are its scale. It suits tasks where the next step follows predictably from what came before. It is poor at anything requiring a change of direction, a large restructuring, or information the user has not yet typed. And because accepting a suggestion is so easy, it invites a particular kind of complacency: users may accept plausible completions without reading them carefully, especially when tired or rushed. The side panel The second pattern places a chat interface alongside the user's main work, in a panel that can see what the user is looking at. Many productivity suites adopted this pattern under the label of a copilot or assistant. The user can ask questions about the current document, request changes, or generate new material, without leaving the application. The side panel improves on a standalone chatbot by giving the model context, so that "summarise this" means something. But it inherits most of chat's problems. The output still appears in a separate place from the work. Transferring a suggestion from the panel into the document is often clumsy. And the user must still compose requests in language, with all the difficulties discussed in the previous chapter. The side panel works best for questions about the material rather than changes to it. "What are the main risks in this contract?" or "Which customers in this spreadsheet have not ordered in six months?" are natural uses, because the answer is information the user wants to read, not content they want inserted. For editing, other patterns usually do better. The shared canvas In 2024 several companies introduced a pattern that addressed chat's linearity directly. Anthropic launched Artifacts in June, displaying code, documents and interactive content in a dedicated pane beside the conversation. OpenAI introduced Canvas in October, a workspace where the user and the model could edit the same document together, with the user able to select passages and request targeted changes. Other products have adopted similar designs under various names. The canvas pattern separates the conversation about the work from the work itself. The conversation becomes a place for instructions and discussion; the canvas holds the evolving artefact, which persists, can be edited directly by the user, and changes in place rather than being regenerated in full each time. This solves several problems at once. The user does not need to scroll back to find the latest version. They can make small edits themselves without asking the model. They can point to a specific part and request a change to only that part. And changes can be shown as differences, so the user sees exactly what the model altered. The canvas pattern fits tasks where the output is a substantial artefact that will be refined over many turns: a report, a piece of code, a presentation, a design. It is unnecessary overhead for quick questions. The design challenge it raises is version control. When both the user and the model are editing the same document, it must be clear who changed what, and it must be easy to revert a model's change without losing the user's own edits. Embedded actions The fourth pattern abandons conversation entirely. Generative capabilities appear as ordinary features within an application: a button to summarise an email thread, a menu option to rewrite selected text in a different tone, an automatic caption for an uploaded image, a suggested reply at the bottom of a message. The user does not interact with an assistant; they use a feature that happens to be powered by a model. This pattern is unglamorous and frequently the most effective. Embedded actions are discoverable, because they sit where users already look. They constrain the request, which makes output more predictable and easier to test. They fit naturally into existing workflows. And they set modest expectations: a "summarise" button promises a summary, not general intelligence. Their weakness is that each one must be designed and built separately, and the set of available actions is fixed by the product team. Users who want something slightly different have no recourse. A common compromise pairs a handful of embedded actions for frequent tasks with a free-text option for everything else. Proactive and ambient features A fifth pattern has the system act without being asked. Notification summaries condense a stack of messages into a sentence. Meeting tools produce notes and action items automatically. Email clients sort, prioritise and draft replies in advance. Search engines display AI-generated overviews above conventional results. Proactive features are where Horvitz's cost-benefit logic bites hardest, because the user did not request the output and may not scrutinise it. When Apple introduced AI-generated notification summaries in late 2024, the feature condensed news alerts as well as personal messages. In December 2024, a summary of BBC News notifications falsely stated that Luigi Mangione, the man charged with killing the UnitedHealthcare chief executive Brian Thompson, had shot himself. The BBC complained publicly. In January 2025, Apple paused summaries for news and entertainment apps, began displaying all summaries in italics to distinguish them from original notifications, and added a note in settings that the feature might contain errors. The episode is instructive precisely because the underlying error was ordinary. Language models compressing several short texts into one will sometimes conflate them. What made the error serious was the pattern: an unrequested summary, displayed in the same visual format as authoritative notifications from a news organisation, on a lock screen where most people glance rather than read. Apple's fixes were all interface changes: visual distinction, scope restriction and an honest disclaimer. Google's AI Overviews provide a similar lesson. Shortly after their broad launch in the United States in May 2024, users circulated examples of absurd answers, including a suggestion to add glue to pizza sauce to make cheese stick, apparently drawn from an old joke post on a discussion forum. Google responded by restricting the queries for which overviews appeared and adding safeguards against satirical and user-generated sources. Again, the error was an ordinary property of the technology; the damage came from placing generated text at the top of search results, the position most users associate with the most authoritative answer. Agents The newest and most consequential pattern is the agent: a system that takes a goal and carries out a sequence of actions to achieve it, often using other software. From late 2024 onwards, several companies released systems that can operate a web browser or a computer desktop, clicking, typing and navigating on the user's behalf. Coding agents can read a code repository, make changes across many files, run tests and iterate. Research agents can search the web for many minutes and produce a report. Agents transform the design problem, because the user is no longer evaluating a single piece of output but delegating a process. The gulf of evaluation widens enormously: the user may not see most of what the agent did, and an error early in a long sequence can propagate silently. At the same time, the potential cost of errors rises, because agents can take actions with real effects, sending messages, making purchases, deleting files. Designing for agents draws on principles covered later in this booklet, especially in Chapter Six. The key questions are how much autonomy to grant, at which points the agent should stop and ask for confirmation, how its progress should be displayed, and how its actions can be reviewed and reversed. A useful analogy is delegating to a new employee: you give clear instructions, you specify what they may do without asking, you check their work at intervals, and you extend more autonomy as they earn it. The dimension of time Every pattern above also has to cope with a property of generative systems that conventional interfaces rarely face: output takes a noticeable and unpredictable time to arrive. A database query returns in milliseconds. A language model producing a long answer may take many seconds; a research agent may take many minutes; an image or video generator anywhere in between. The most common response is streaming, displaying text as it is generated, word by word. Streaming makes waiting feel shorter, because the user sees progress immediately and can begin reading before the answer is complete. It also has costs. The user may start acting on the beginning of an answer that the end will qualify or contradict. The layout jumps as content arrives, which makes reading harder. And streaming makes it impossible to check an answer before showing it, since the answer does not exist in full until it has been shown. Products that want to run a verification step, checking citations, filtering unsafe content, confirming a calculation, must either delay display or retract content after showing it, and retraction is jarring. For longer tasks, the design problem shifts from making waiting tolerable to making it productive. A user who asks an agent to research a topic for ten minutes does not want to watch a spinner. They want to do something else and be told when the work is finished, with a summary of what was done. Background execution with notifications, a pattern familiar from file downloads and software builds, suits these tasks better than a conversation that holds the user's attention hostage. Progress indication is unusually difficult, because the system often does not know how long a task will take or how many steps it involves. A conventional progress bar implies a known total, which is misleading. Better designs show what the system is currently doing, searching, reading a particular source, drafting a section, so that the user can judge progress and spot when the task has gone off course. This also serves verification: a user who watched the agent read three sources knows what the resulting report was based on. Finally, latency interacts with variability. If each attempt takes thirty seconds, regenerating to get a better result is expensive, and users will accept outputs they would otherwise have rejected. Patterns that produce several variants in parallel, or that allow partial regeneration of only the weak part, reduce the cost of trying again, and in doing so they reduce the pressure to settle for the first answer. Choosing a pattern No single pattern suits every task, and many products combine several. The choice depends on a handful of factors, which Table 2 compares across the patterns described here. Table 2. Common interaction patterns for generative features compared. Pattern Who initiates Size of each output Ease of checking Best suited to Inline completion System, continuously A word to a few lines High; read at a glance Predictable continuation of the user's own work Side panel chat User A paragraph to a page Moderate Questions about material in view Shared canvas User, iteratively Whole document or file Moderate; changes shown as edits Substantial artefacts refined over many turns Embedded action User, one click Bounded by the feature High; scope is narrow Frequent, well-defined tasks Proactive feature System, unasked Short summaries or drafts Low; often glanced at Low-stakes condensing and triage Agent User sets goal, system acts Many steps and actions Low unless designed for review Multi-step tasks with reviewable checkpoints Several principles follow from the comparison. The first is that the size of the output should match the user's capacity to evaluate it. Small outputs, a line of code, a sentence, a single image, can be judged quickly, and patterns that produce them can afford to be fluid and frequent. Large outputs, a whole report, a set of changes across fifty files, need patterns that support structured review. The second is that initiative should track confidence and stakes. The more the system acts unasked, the more confident it should be and the cheaper its errors should be. Proactive summaries of personal chats are tolerable; proactive summaries of breaking news proved not to be. An agent that books a restaurant table can perhaps act freely; one that transfers money should not. The third is that output should land where the work is. Patterns that keep generated content separate from the material it concerns impose a transfer cost on every interaction. Patterns that integrate it, inline completion, canvas, embedded actions, reduce that cost and make it easier to see the output in context, which is also where it is easiest to judge. The fourth is to prefer the most constrained pattern that serves the need. A specific button is more predictable than a side panel, which is more predictable than an agent. Constraint is not a failure of ambition; it is what makes a feature testable, explainable and trustworthy. Teams should reach for open-ended conversation or autonomous action only when the task genuinely requires it. The Dell'Acqua study described in the introduction offers a final consideration. Observing how consultants worked with GPT-4, the researchers identified two successful styles. Some behaved like centaurs, dividing work cleanly between themselves and the model, delegating some subtasks entirely and keeping others for themselves. Others behaved like cyborgs, intertwining their effort with the model's at a fine grain, continually passing work back and forth. Different interaction patterns support these styles differently. Embedded actions and agents suit the centaur's clean delegation; inline completion and the shared canvas suit the cyborg's close collaboration. A product that offers only one style forces every user into it, whatever the task. The better products let people move between them. Whatever pattern is chosen, one problem accompanies it everywhere: the output will sometimes be wrong. The next chapter turns to that problem directly. Hashtags: #UXDesignForAI #GenerativeAIInterfaces #HumanAIInteraction #CalibratedTrust #GenerativeVariability #NonDeterministicSystems #JaggedTechnologicalFrontier #AIHallucinations #AITrustCalibration #GulfOfEnvisioning #GulfOfEvaluation #PromptDesign #PromptScaffolding #StructuredInputs #DirectManipulation #SystemPrompts #AITransparency #SourceVerification #HumanInTheLoop #InlineCompletion #SharedCanvas #EmbeddedAIActions #AgenticInterfaces #MixedInitiativeInteraction #FutureOfAIUX

Download the Book (PDF): Introduction Somewhere in a kitchen, a person with flour on their hands says, "Set a timer for twelve minutes." A cylinder on the counter answers, "Twelve minutes, starting now." Nothing about that exchange looks like design. There is no screen, no button, no menu, no icon. And yet almost every word of the reply was decided by someone: the choice to echo back "twelve minutes" rather than say "OK"; the choice not to ask "Did you say twelve or twenty?"; the choice to put the confirmation first and the reassurance ("starting now") last, so that the most important information arrives before attention drifts. If the system had said "I have successfully created a new timer with a duration of twelve minutes, which has now begun counting down," the person would have been annoyed without quite knowing why. If it had said only "OK," a small number of people would have walked away with a timer set for twenty minutes and a burnt loaf. This booklet is about the craft hiding in exchanges like that one. Voice user interface design, usually shortened to VUI design, is the discipline of shaping spoken interaction between people and machines. It overlaps with conversation design, the broader practice that also covers text chatbots, but voice has constraints that text does not. A spoken sentence vanishes as it is heard. It cannot be skimmed, scrolled back, or glanced at again. It arrives one word at a time, at the speaker's pace rather than the listener's. The person on the other end may be cooking, driving, holding a child, or standing across the room. They may have a strong regional accent, a speech impairment, or a television on in the background. They have no visible menu telling them what is possible and no cursor showing them where they are. The argument of this book The controlling idea of what follows is simple to state and surprisingly far-reaching: designing for voice is designing for a listener with no screen and a limited memory, and every good decision in the field follows from respecting those two facts. The listener cannot see what the system can do, so the design must reveal possibilities through speech without reciting a manual. The listener cannot hold much in mind at once, so the design must ration information, order it carefully, and carry context forward so the person does not have to. And because the channel between speaker and machine is noisy and the machine's understanding is fallible, the design must treat misunderstanding as an ordinary event to be repaired gracefully rather than an exception to be apologised for. This idea matters more now, not less, because the technology underneath voice assistants has changed dramatically. For roughly a decade, from the launch of Amazon's Echo in late 2014 to the middle of the 2020s, building for a smart speaker meant defining a fixed set of intents (the goals a user might have), listing sample phrases for each, and writing scripted responses. Large language models have now replaced much of that machinery. Amazon's Alexa+, announced in February 2025 and opened to all Prime members in the United States in February 2026, is built on large language models and orchestrates what Amazon calls "experts" across many services. Google has replaced its Assistant with Gemini on Nest speakers and displays through its Gemini for Home programme, and in September 2026 began a mandatory transition from Assistant to Gemini on Android phones. Google had already shut down its third-party Conversational Actions platform in June 2023. It would be easy to conclude that conversation design is therefore obsolete: if the model can understand anything, why design anything? The answer this book defends is that the model changes the plumbing but not the listener. A language model can parse an oddly phrased request, but it cannot make a forty-second spoken answer easy to remember. It can hold more context than an old dialogue manager, but it can also hold the wrong context and act confidently on it. It can produce fluent, warm-sounding replies, but warmth without honesty is a liability in a device that lives in people's homes. The questions VUI designers have always asked — what does the listener need to hear, in what order, with what confirmation, and what happens when we get it wrong — are still the questions that decide whether a voice product is trusted or abandoned. What this booklet covers The chapters move from the nature of the medium to the practice of building for it. Chapter 1 sets out why the ear is not the eye: the cognitive and practical constraints of speech as an interface, and the short history that took voice from telephone menus to kitchen counters. Chapter 2 turns to intent recognition, the problem of working out what someone means from what they say, and compares the older intent-and-slot model with the language-model approach now replacing it. Chapter 3 examines the single turn: how prompts are written, how confirmations are chosen, how lists are spoken, and how the sound of speech itself can be shaped. Chapter 4 addresses conversational context, the work of holding a thread across several turns and across days, along with the privacy questions that memory raises. Chapter 5 is about failure. Speech recognition errors, silence, misheard names and misunderstood requests are not edge cases; they are the daily texture of voice interaction, and they fall unevenly across speakers. This chapter sets out a practical approach to repair. Chapter 6 considers persona: the character a system projects through its voice and word choice, what empathy can and cannot honestly mean for a machine, and the ethical problems that come with designing something people instinctively treat as social. Chapter 7 surveys the platforms as they actually stand in late 2026 — what remains of the Alexa Skills Kit, what Amazon offers developers for Alexa+, what Google's retreat from third-party voice apps leaves behind — and what a designer can realistically build. Chapter 8 covers testing and measurement, from reading scripts aloud to analysing live transcripts. The conclusion draws the argument together and considers where the discipline goes next. Who this is for The book is written for anyone who needs to understand how spoken interaction works well: product managers deciding whether voice belongs in their service, designers moving from screens to speech, developers who want their skills and agents to feel less mechanical, writers asked to script a brand's voice, and curious readers who want to know why their speaker sometimes seems clever and sometimes seems obtuse. No programming knowledge is assumed. Where technical terms are needed, they are defined in place. A word on examples. Many illustrations in the following chapters are short dialogues, written as they would be spoken. Some are drawn from documented platform guidance and published research; others are constructed to show a principle clearly, and these are presented as illustrations, not as transcripts of real products. Where a specific figure, date or finding is given, it comes from a named source listed in the Notes. The best way to read the dialogues is aloud. That is not a stylistic flourish; it is the first and most useful technique in the whole discipline. A prompt that looks crisp on the page often turns out, when spoken, to be too long, to bury its key word, or to end on a phrase that invites the wrong reply. The ear catches what the eye forgives. If this booklet leaves its readers with one habit, it should be that one. Chapter 1: The Ear Is Not the Eye A web page is a place. You arrive, look around, take in the layout at a glance, and then decide where to look more closely. Your eye can jump from a heading to a price to a button in a fraction of a second, and if you forget something you look again. Almost everything designers have learned about digital interfaces over the past forty years assumes this freedom: the user scans, the user chooses the order, the user can return. Speech takes all of that away. A spoken response is not a place but an event. It begins, unfolds at a fixed pace, and ends, and once a word has been said it is gone unless the listener has held on to it. The listener cannot skim ahead to see whether the useful part is coming. They cannot glance back to check the second item in a list. They cannot see that there are three options before the system starts reading the first. Understanding voice design begins with taking these differences seriously, because nearly every rule of the craft is a consequence of them. Linear, ephemeral and paced by the speaker Three properties of speech shape everything else. The first is that speech is linear. Information arrives in a single file, one word after another. On a screen, a designer can place a summary at the top and details below, and the reader can decide how far to go. In speech, the order of words is the layout. If the important thing comes last, the listener must sit through everything before it. If a qualification comes after a claim, the listener has already acted on the claim in their head before hearing the qualification. "Your flight is on time — the departure gate has changed to B14" works. "The departure gate for your flight, which is on time, has changed from A3 to B14" asks the listener to hold three things before any of them is resolved. The second is that speech is ephemeral. It leaves no trace. A person reading a recipe can look back at the oven temperature; a person listening to one must either remember it or ask again. This is why voice interfaces that read long passages of text perform so poorly. Written prose relies on the reader being able to re-read. Prose written for the ear must instead build in redundancy, repeating key items at the moment they are needed rather than assuming they were retained from earlier. The third is that speech is paced by the speaker, not the listener. A reader controls speed: slowing down on a hard sentence, racing through a familiar one. A listener cannot. Conversational English is commonly spoken at around 150 words per minute, while skilled readers take in non-fiction text considerably faster than that when reading silently. So a voice interface delivers information more slowly than a screen, and at a rate the user cannot adjust in the moment. Every unnecessary word costs the user real time — perhaps half a second — and they are aware of each one. Taken together, these properties mean that a spoken interface can carry much less information per interaction than a visual one, and that how it orders and rations information matters far more. The limits of working memory The second constraint lives inside the listener. Working memory, the mental workspace where we hold information while using it, is small. George Miller's famous 1956 paper suggested people could hold "seven, plus or minus two" items; later work, notably by Nelson Cowan, argued that the true limit for unrelated items is nearer four chunks when rehearsal and grouping are controlled for. The exact number matters less than the direction: people can hold only a handful of new things in mind at once, and the hold decays within seconds unless rehearsed. On a screen, this limit rarely bites, because the screen itself acts as external memory. The options stay visible. In speech, the listener's working memory is the only place the options live. Ask someone to choose among six spoken options and by the time the sixth arrives, the first two have faded. Many people will simply choose the last thing they heard, or ask for the list again, or give up. Older telephone systems taught this lesson painfully. The interactive voice response (IVR) menus of the 1990s and 2000s — "For billing, press one. For technical support, press two..." — were notorious precisely because they made callers hold long lists while waiting to hear whether their need was even included. Designers learned to keep menus short, put the most common options first, and say the option before the number ("For billing, press one" rather than "Press one for billing"), so callers knew what they were choosing before being told how. Those lessons transfer almost unchanged to smart speakers, and they will appear again in Chapter 3. Working memory also explains why voice is so much better at some tasks than others. Tasks with a single clear goal and a short answer — set a timer, play a song, turn off the lights, what's the weather — fit comfortably. Tasks that require comparing several options on several attributes — choosing a hotel, reviewing a bank statement, picking a flight — fit badly, because the comparison has to happen in the listener's head. This is the deepest reason why, a decade after the smart speaker arrived, the most common uses remain music, timers, weather, questions and smart-home control. It is not that users lack imagination. It is that the medium favours short, single-purpose exchanges. Invisible affordances The third constraint is that voice has no visible affordances. In design, an affordance is a property of an object that suggests how it can be used: a button looks pressable, a handle looks pullable. Screens are dense with affordances. A user who has never used an app before can see its menus and controls and work out roughly what it does. A smart speaker offers almost none. It sits silently, and the only clue to its capabilities is the knowledge the user brings. This creates what designers call the discoverability problem. People do not know what they can say, and the system has no unobtrusive way to tell them. Reciting capabilities is tedious; staying silent leaves users trapped in the handful of commands they already know. Research on real household use bears this out. Studies of how families actually use voice assistants, such as Martin Porcheron and colleagues' 2018 analysis of recordings of Echo use in homes, found that interaction is woven into other activities — family meals, conversations, chores — and that people develop their requests collaboratively, rephrasing and prompting one another when the device fails to understand. Ewa Luger and Abigail Sellen's 2016 interview study of conversational agent users, memorably titled "Like Having a Really Bad PA", found a persistent gap between what users expected of the system and what it could actually do, and that users tended to scale back their ambitions to a few reliable tasks after early failures. That pattern — early exploration, a few disappointments, retreat to a small set of safe commands — is the natural consequence of invisible affordances combined with fallible understanding. Good voice design fights it in two ways. It makes the system tolerant of the many ways people phrase things, so that a first attempt usually succeeds. And it offers capability hints at the right moment and no other: telling a user who has just set a timer that they can also name timers, for example, but not reciting a list of features every time the device wakes. Where voice wins None of this means voice is a poor interface. It means voice is a particular one, with a distinctive profile of strengths, and good design starts by matching tasks to that profile. The most striking feature of the profile is an asymmetry between input and output. Speaking is a fast way to put information into a system. Most people speak far faster than they type, especially on a phone; a 2016 study led by Sherry Ruan and James Landay at Stanford found that speech recognition was about three times faster than typing on a smartphone keyboard for short English messages, with fewer errors once corrections were counted. Listening, by contrast, is a slow way to get information out. So voice is at its best when the user says something rich and the system replies with something brief: "Remind me to call the dentist when I get to work on Monday" is a complex request delivered in three seconds, and "OK, I'll remind you Monday when you arrive at work" is a short, checkable reply. Voice is at its worst when the user says something short and the system must reply with something long: "What's on my calendar this week?" invites a monologue nobody can retain. The second strength is that voice frees the hands and eyes. That makes it valuable whenever both are busy: in the kitchen, in the car, at a workbench, while carrying a child. Many of voice's most loyal uses arise from exactly this situation rather than from any preference for speech as such. A person who would happily tap a screen to set a timer while sitting at a desk will gladly speak to set one while kneading dough. The third strength is accessibility. For many blind and partially sighted people, voice assistants offer a direct route to information and control that screens make laborious. For people with limited mobility or dexterity, speaking to turn on lights or adjust heating can restore a measure of independence. For some older adults uncomfortable with touchscreens, speech is simply a more natural way to use technology. These users are not edge cases; they are among the people for whom voice design matters most, and their needs sharpen every principle in this book. A system that relies on a companion screen for anything essential fails them first. The fourth strength is presence. A speaker in a room can be addressed by anyone in it, from anywhere in it, without picking anything up. That makes it a shared household utility in a way phones are not, and it explains why the communal uses — music, timers, shopping lists, smart-home control — dominate. It is also the source of the privacy and multi-user problems discussed later, because a device addressed by everyone hears everyone. Speech is social The fourth property is less obvious but just as important: speech is the medium of human social life, and people cannot entirely switch off their social instincts when talking to a machine. Clifford Nass and his collaborators showed in a series of experiments in the 1990s and 2000s, summarised in the book Wired for Speech, that people apply social rules to computer voices: they are polite to them, attribute gender and personality to them, and respond to them as they would to a person, even when they know perfectly well they are talking to software. This has two consequences for design. First, users bring the norms of human conversation to their interaction. They expect the system to take turns properly, to remember what was just said, to answer the question asked rather than a slightly different one, and to signal when it has not understood. When a system breaks these norms, users do not experience it as a neutral technical failure; they experience it as rudeness, stupidity or evasion. Second, every choice of wording, voice and tone communicates character, whether the designer intends it or not. There is no neutral voice. A system that says "Sorry, I didn't catch that" has a personality, and so does one that says "Error. Please repeat." Chapter 6 returns to this. The philosopher H. P. Grice's account of conversational cooperation, published in 1975, gives a useful framework for those norms. Grice proposed that people in conversation assume each other to be following a cooperative principle, which he broke into four maxims: say as much as is needed and no more (quantity); say what you believe to be true (quality); be relevant (relation); and be clear, brief and orderly (manner). When a speaker appears to break a maxim, listeners infer an extra meaning rather than assuming incompetence. A machine that over-explains seems condescending; one that answers a different question seems evasive. Grice's maxims are not rules a voice system can mechanically follow, but they are an excellent checklist for reading a script aloud and asking where it would irritate a human listener. From telephone menus to the kitchen counter Voice interfaces did not begin with smart speakers. Bell Laboratories built a system called Audrey in 1952 that could recognise spoken digits from a single speaker. IBM demonstrated its Shoebox machine, which understood sixteen spoken words, at the 1962 Seattle World's Fair. For decades after, speech recognition was a research curiosity, limited to small vocabularies, single speakers or careful, isolated words. The first mass encounter most people had with voice interfaces came over the telephone. From the 1990s, banks, airlines and utilities deployed speech-enabled IVR systems that let callers say "billing" instead of pressing a key. These systems were built with formal grammars — explicit lists of acceptable phrases — and designers developed a substantial body of practice around them, captured in books such as Michael Cohen, James Giangola and Jennifer Balogh's Voice User Interface Design (2004). Much of what is now called conversation design was worked out in that era: how to write prompts, how to confirm, how to escalate help after repeated failures, how to give callers a way out. Dictation software improved through the 1990s and 2000s, and the arrival of Apple's Siri on the iPhone 4S in 2011 brought a general-purpose voice assistant to a mass audience. But the phone was still primarily a screen device, and voice was an optional extra. The decisive shift came when Amazon announced the Echo in November 2014: a device with no screen at all, designed to sit in a room and respond to a wake word from across it. Google followed with Google Home in 2016. Within a few years smart speakers were in many millions of homes, and both companies opened their platforms to outside developers — Amazon through the Alexa Skills Kit and Google through Actions on Google — inviting anyone to build voice applications. That opening created a new profession almost overnight. Brands, publishers, game studios and hobbyists built tens of thousands of skills, and companies hired conversation designers to script them. It also exposed how hard the medium is. Most third-party skills attracted little sustained use. Users struggled to remember the invocation names needed to start them, and many experiences that worked on paper proved tedious when spoken. By the early 2020s, both Amazon and Google were scaling back their investment in third-party voice apps, a story Chapter 7 tells in full. The latest shift is the arrival of large language models as the engine of voice assistants. Their ability to handle open-ended phrasing and sustain longer exchanges removes some old constraints. But it leaves the fundamental ones untouched. A language model still speaks to a listener who cannot scan, cannot scroll and cannot hold more than a handful of things in mind. If anything, the fluency of these models raises the stakes: they are capable of producing long, articulate, well-formed answers that are perfectly suited to the eye and poorly suited to the ear. What follows from the medium It is worth drawing together the practical consequences of everything in this chapter, since the rest of the book elaborates them. Responses should be short, with the most important information first and the details offered rather than imposed. Lists should be brief, and the user should be told how many items there are before hearing them. Options should be named before the user is asked to choose, and the choice should be easy to state. Context should be carried by the system rather than the user: if the conversation has established which city we are talking about, the user should not need to say it again. Misunderstandings should be expected and repaired without blame. And capabilities should be revealed gradually, at the moment they become relevant. None of this is exotic. It is what a considerate person does when giving directions over the phone, reading a menu to a friend who has forgotten their glasses, or explaining something to a colleague who is driving. The craft of voice design consists largely of noticing what considerate human speakers do without thinking, and making it explicit enough that a machine can do it reliably. Chapter 2: What People Mean When someone says "wake me at seven," a voice system faces a chain of problems before it can do anything useful. It must notice that it is being addressed. It must turn a stream of sound into words. It must work out that those words are a request to set an alarm rather than, say, a question about sunrise. It must determine that "seven" means 7:00, decide whether that is morning or evening, and decide which day. Only then can it act, and only then can it compose a reply and turn that reply back into sound. This chain is worth understanding in some detail, because each link fails in its own way, and a designer who knows where failure comes from can design around it. The central link — working out what the person wants — is called intent recognition, and it is the heart of this chapter. The pipeline from sound to action Classic voice assistants process a request in a series of stages, each handled by a separate component. The first is wake-word detection. A small model running on the device listens continuously for a trigger phrase such as "Alexa" or "Hey Google". It is designed to run on little power and to respond only to that phrase, so that the device does not send everything said in the room to the cloud. False wakes, when the device mistakes a television voice or a similar-sounding word for its name, and missed wakes, when it fails to hear its name, are the first failure points. The second is automatic speech recognition (ASR), which converts audio into text. Modern ASR uses large neural networks trained on vast amounts of speech, and in favourable conditions it is very accurate. Conditions in a home are often not favourable: background noise, distance from the microphone, overlapping speech, children's voices, accents underrepresented in training data, and unusual names all degrade accuracy. ASR does not produce a single certain answer; it produces a ranked set of hypotheses, known as an n-best list, each with a confidence score. Whether downstream components can see that uncertainty, or only the top guess, matters a great deal for error handling. The third is natural language understanding (NLU), which takes the transcribed words and works out what they mean in terms the system can act on. Traditionally, this produces two things: an intent, which is the user's goal, and a set of slots (also called entities or parameters), which are the variable details that goal needs. "Wake me at seven tomorrow" becomes the intent SetAlarm with slots for time (07:00) and date (tomorrow). The fourth is dialogue management, which decides what to do next given the intent, the slots and the state of the conversation. If all the needed information is present, it calls the relevant service. If something is missing — the user said "set an alarm" without a time — it asks for it. If something is ambiguous, it may ask for clarification or make a reasonable assumption. The fifth is response generation, which composes what the system will say, and the sixth is text-to-speech (TTS), which turns that text into audio. Modern neural TTS voices are remarkably natural, and markup languages such as the W3C's Speech Synthesis Markup Language (SSML) let designers control pauses, emphasis and pronunciation, a subject Chapter 3 picks up. Language-model-based assistants blur some of these boundaries, but the logical steps remain. Something must hear, something must transcribe, something must interpret, something must decide, and something must speak. Intents, utterances and slots For about a decade, almost every third-party voice application was built using a model of intents, sample utterances and slots. It remains the clearest way to understand intent recognition, and it is still how classic Alexa skills are built. In the Alexa Skills Kit, a developer defines an interaction model. It has an invocation name, the phrase users say to open the skill ("Alexa, open Daily Recipes"). It has a set of custom intents, each representing something the user can ask for: FindRecipeIntent, NextStepIntent, AddToShoppingListIntent. For each intent, the developer supplies sample utterances, examples of how users might phrase the request: "find me a recipe for {dish}", "what can I make with {ingredient}", "I want to cook {dish}". The words in braces are slots, each with a slot type that defines what values it can take. Amazon supplies built-in slot types for common categories such as dates, numbers, times, cities and first names, and developers can define custom types with their own value lists and synonyms. Amazon also supplies built-in intents for actions every skill should handle consistently: AMAZON.HelpIntent, AMAZON.StopIntent, AMAZON.CancelIntent, AMAZON.YesIntent, AMAZON.NoIntent, AMAZON.RepeatIntent and AMAZON.FallbackIntent, the last of which catches requests that match nothing else. Using these matters because users expect "stop", "cancel" and "help" to work the same way everywhere. Google's equivalent, before Conversational Actions were shut down in 2023, used Dialogflow and later the Actions Builder, with broadly the same concepts: intents trained on example phrases, entities for the variable parts, and contexts to control which intents were active at a given moment. The important thing to understand is that the sample utterances are not an exhaustive list. They are training examples. The platform's NLU model generalises from them to recognise similar phrasings it has never seen. Good interaction models therefore supply varied examples — different word orders, short and long forms, with and without politeness words, with slots in different positions — because a model trained only on "find me a recipe for {dish}" will struggle with "what's a good {dish} recipe". Why intent models break The intent-and-slot approach is precise, predictable and testable. It also has well-known weaknesses, and they shaped how voice applications felt to use. The first weakness is that it is a closed world. The system can only recognise the intents it has been given. Anything else either falls into a fallback intent or, worse, gets forced into the nearest match. A user of a recipe skill who asks "how long will this keep in the fridge?" may find their question interpreted as a request for the next step, because NextStepIntent was the closest thing the model knew. Mis-mapping of this kind is more damaging than an honest "I can't help with that", because the user gets a confident wrong answer. The second is utterance overlap. As an interaction model grows, intents start to share phrasings. "Play the next one" might belong to a music intent or an episode intent. Designers had to watch for conflicts between their own intents and between their skill and the platform's built-in commands. The third is slot brittleness. Slots work well for structured values like dates and numbers, and poorly for open-ended ones like dish names, book titles or personal names, where the space of possible values is huge and ASR errors are common. A custom slot type listing five hundred dishes will not recognise the five hundred and first. Designers compensated with synonym lists and entity resolution, which maps varied spoken forms ("mac and cheese", "macaroni cheese") to a canonical value, but the gaps were always there. The fourth is the invocation problem. Because each third-party skill lived in its own closed world, the user had to name it to enter it: "Alexa, ask Daily Recipes for a pasta dish." People rarely remember invocation names. Amazon experimented with name-free interaction, in which the platform routes a general request ("Alexa, find me a pasta recipe") to a suitable skill without the user naming it, using signals such as a skill's declaration that it can fulfil a given request. This helped, but routing between thousands of independently built closed worlds was always going to be imperfect. Finally, the intent model put the burden of anticipation on the designer. Every path a conversation could take had to be foreseen and scripted. Real users wander off script constantly — changing their minds, asking side questions, answering a question with a question — and each unforeseen move was a potential dead end. The language-model shift Large language models change intent recognition fundamentally. Instead of classifying an utterance into one of a fixed set of intents, a language model can interpret the request in open language and decide what to do with it. In current assistants, this typically works through what is often called tool use or function calling: the model is given descriptions of available actions — set an alarm, search recipes, add to list, call a booking service — together with what parameters each needs, and it decides which to call and with what values, or whether to answer directly, or whether to ask a clarifying question. Amazon's description of Alexa+ reflects this architecture. It describes the system as built on large language models available through Amazon Bedrock, coordinating what it calls "experts": groupings of capabilities and APIs for particular kinds of task. The developer tools Amazon announced alongside Alexa+ — an AI Action SDK for connecting services through APIs, a Web Action SDK for letting Alexa operate a partner's website, and a Multi-Agent SDK for connecting specialised agents — all follow the same pattern: the developer describes capabilities and the model decides when and how to use them, rather than the developer enumerating phrasings. The gains are real. The open-world model handles phrasings no designer anticipated. It copes with compound requests ("turn off the lights and set an alarm for six"), with indirect requests ("it's a bit dark in here"), and with corrections in mid-sentence ("set a timer for ten — no, fifteen minutes"). It can carry context from earlier in a conversation much more flexibly than a slot-based dialogue manager. And it largely removes the invocation problem, because the system can route a request to a capability without the user knowing the capability's name. The costs are also real, and they matter to designers. First, behaviour is less predictable. An intent model, given the same utterance, produces the same intent every time; a language model may vary. That makes testing harder and makes certain failures — a confidently wrong action, an invented fact — possible in ways they were not before. Second, language models are verbose by default. Trained largely on written text, they tend toward thorough, well-structured, paragraph-length answers that suit a screen and overwhelm a listener. Getting them to speak in short, ear-friendly turns requires deliberate instruction and evaluation. Third, they introduce latency. Calling a large model, then perhaps a tool, then perhaps the model again takes time, and in voice, silence after a request feels much longer than a spinner on a screen. Fourth, actions with consequences become riskier. A system that can book, buy and control devices on the basis of open interpretation needs careful rules about when to confirm before acting, a subject Chapter 3 takes up. Three models compared The three broad generations of intent recognition differ on the dimensions that matter most to designers, as Table 1 sets out. The comparison is not a ranking: each approach fits some situations better than others, and many real systems combine them, using a language model for interpretation but passing high-stakes actions through deterministic, intent-like handlers. Table 1. Three approaches to intent recognition compared. Approach How meaning is found Strengths Typical failures Designer's main job Grammar-based (classic IVR) Exact match to a written grammar Predictable, fast, easy to test Rejects anything off-grammar Write grammars and tight prompts Intent and slot (classic skills) Trained classifier over sample utterances Generalises to similar phrasings; testable Forced mis-mapping; brittle open slots; invocation names Define intents, utterances, slot types, dialogue flows Language-model orchestration Model interprets and selects tools Handles open phrasing, compound and indirect requests Variable behaviour; verbosity; latency; confident errors Describe capabilities, set constraints, design confirmations and repair One task, two designs A concrete comparison makes the difference tangible. Imagine a regional cinema chain that wants customers to be able to check showtimes and book seats by voice. Under the intent-and-slot model, the team would define intents such as FindShowtimesIntent, BookTicketsIntent, and perhaps CheckBookingIntent. For FindShowtimesIntent they would write dozens of sample utterances — "what's on tonight", "when is {film} showing", "times for {film} at {cinema} on {date}" — and define slot types for film titles (refreshed every week as the programme changes), cinema locations, dates and times. They would design the dialogue flow: if the user names a film but no cinema, ask which cinema; if they name neither, offer the three most popular films. They would write prompts for each missing slot, confirmations, and error messages for each failure. Every Friday, when new films opened, someone would update the film-title slot values, and every time a customer used a nickname for a film or a cinema — "the one in town", "the new Bond" — the system would probably fail. Under the language-model approach, the team would instead describe two or three capabilities. A showtime search that takes an optional film, cinema, date and time range and returns matching screenings. A booking action that takes a screening and a number and type of seats and returns a confirmation. A booking lookup. Each description would say clearly what the capability does, what each parameter means, and what it returns. The model would handle "what's on at the one in town tonight" by reasoning that "the one in town" probably refers to the city-centre cinema, perhaps confirming, and calling the search. The second design is far less work to build and far more tolerant of how people actually speak. But notice what it does not settle. Should the assistant read out every showing of every film tonight, or summarise? If there are fourteen screenings, which three should it mention first? Should it confirm before booking, and what exactly should it read back? What if the user asks for a film that is not showing — should it say so and suggest an alternative, or ask whether they meant something similar? What if they ask whether the film is suitable for an eight-year-old — is the assistant permitted to answer, and from what source? All of these remain design decisions, and in the language-model design they have to be written down as instructions and tested, rather than built into a flow. Many teams discover that the description of a capability — what it is for, when to use it, what to say about its results — is itself a piece of conversation design, and a surprisingly delicate one. What the designer still owns It is tempting to read the language-model shift as the end of intent design. It is better read as a change in where the designer's effort goes. Under the intent model, much of the work was enumerating: listing intents, writing utterances, filling slot values. Under the language-model approach, much of that enumeration is unnecessary. But the decisions behind it are still needed. Someone must still decide what the system can and cannot do, and how it should say so. A language model will try to be helpful about almost anything; a product must decide where its competence ends and make that boundary audible, so users are not led to depend on answers the system is not qualified to give. Someone must still decide which actions need confirmation and which can proceed silently. Someone must still decide what the system should do when the request is ambiguous — ask, assume, or offer a choice. And someone must still decide the shape of the reply: its length, its order, the words it uses, and what it leaves for the user to ask about. There is also a subtler point. Intent design was never only about classification. Writing sample utterances forced designers to imagine how real people speak about a task, which in turn shaped how the system spoke back. The best practitioners collected real phrasings from users before writing anything, often by asking people to describe what they would say, or by running sessions in which a hidden human played the system. That practice remains just as valuable when a model handles the parsing, because it is the best evidence of what users expect, which words they use for things, and which tasks they actually bring. A system that understands every phrasing but answers in the product team's vocabulary rather than the user's will still feel foreign. Intent recognition, in other words, has moved from being a problem the designer solves by hand to a problem the model solves with guidance. The guidance — what the system is for, what it should never do, how it should sound, when it should check — is where conversation design now lives. Chapter 3: Designing the Turn A conversation is built from turns: one party speaks, then the other. In human talk, turns are negotiated with extraordinary speed and subtlety. The sociologists Harvey Sacks, Emanuel Schegloff and Gail Jefferson, in a landmark 1974 paper on the organisation of turn-taking, showed that speakers manage transitions so precisely that gaps and overlaps are typically very brief, using cues of grammar, intonation and gaze to project when a turn is about to end. Voice systems have none of that natural fluency. Each turn they take is a designed object, and the quality of a voice experience rests largely on how well those objects are built. This chapter treats the single system turn: what goes into it, in what order, and how it hands the floor back to the user. The anatomy of a good turn Most system turns do some combination of three jobs. They acknowledge what the user said, so the user knows they were heard. They deliver something: an answer, a result, a confirmation of action. And they prompt the user for what comes next, if anything does. Not every turn needs all three, and many of the best turns contain only one. Consider a user who asks a cooking assistant, "How long do I boil an egg for a soft yolk?" A good reply might be: "About six minutes, once the water's boiling." That is pure delivery: the acknowledgement is implicit in answering the right question, and no prompt is needed because the user's goal is met. Adding "Great question! For a soft-boiled egg with a runny yolk, you'll want to boil it for approximately six minutes. Would you like more egg tips?" adds nothing but time, and the closing question imposes a decision the user did not ask to make. The order of the elements matters because speech is linear. Put the answer first and supporting detail after, so a listener who stops paying attention still has what they need. Put the prompt last, because the last thing said is what the user responds to. A turn that ends with something other than its question invites confusion: "Which size would you like — small, medium or large? Large is our most popular." The user has been asked a question and then given a statement; many will hesitate, unsure whether the system has finished. That leads to one of the most reliable rules in the discipline: if you want the user to speak, end with the question, and make it clear that you are asking. A rising intonation, a clear interrogative, and then silence. Turns that bury the question mid-sentence, or ask two questions at once ("Do you want to hear the ingredients or should I start the steps, and how many people are you cooking for?"), reliably produce confused or partial answers. Open and directed prompts Prompts vary in how much they constrain the answer. An open prompt — "What would you like to cook?" — gives the user freedom and suits experienced users who know what they want. A directed prompt — "Would you like a vegetarian or a meat dish?" — narrows the space of likely answers and suits users who need guidance, or situations where recognition is difficult. The choice used to be driven largely by recognition limits. With grammar-based systems, an open prompt invited answers the system could not understand, so designers leaned heavily on directed prompts. With modern NLU and language models, open prompts are far more viable. But directed prompts remain valuable for a reason that has nothing to do with recognition: they tell the user what is possible. In a medium with no visible affordances, a directed prompt doubles as a menu. "You can ask for today's specials, check your order, or book a table" is both a prompt and a lesson in what the service does. A useful middle ground is the open prompt with examples: "What would you like to cook? You could say something like 'a quick pasta dish' or 'something with chicken'." The examples model the kind of phrasing the system handles well without restricting the user to them. Designers should pick examples carefully, because users tend to copy them closely. The most common mistake is to use the same prompt for everyone. First-time users benefit from guidance; repeat users find it tedious. Good systems shorten their prompts as users demonstrate familiarity — a technique often called tapering — so that the hundredth interaction is brisk while the first is supportive. Speaking lists Lists are where the limits of working memory bite hardest. A screen can show twenty search results; a speaker cannot reasonably read more than a few. The practical guidance that emerged from IVR and smart-speaker design is consistent. Offer no more than about three options at once when the user must choose among them. Say how many items there are before reading them, so the listener knows how much to hold: "I found three Italian restaurants nearby." Read the most relevant first. Keep each item short, naming only the attribute most likely to drive the choice. Pause briefly between items. And after the list, make the selection easy: "Which one would you like?" with the expectation that users will answer by name, by position ("the second one"), or by attribute ("the cheaper one"), all of which the system must handle. When there are more results than can be read, the system should say so and let the user narrow them rather than paging through: "There are over twenty. Do you want to narrow it down by price or by distance?" Paging ("Here are the next three...") is sometimes unavoidable, but every page further taxes memory, and by the third page few users remember the first. For longer content the listener needs to follow rather than choose from — recipe steps, directions, instructions — a different discipline applies. Deliver one step at a time, wait for the user to signal readiness ("next"), and make "repeat" and "go back" always available. Recipes are a good test of any voice design because the user's hands are busy, attention is divided, and the cost of mishearing a quantity is a ruined dish. Confirmation: how sure do we need to be? Every time a system acts on its interpretation of a request, it risks acting on a misunderstanding. Confirmation is how it manages that risk, and choosing the right confirmation strategy for each situation is one of the most consequential decisions in voice design. There are three main strategies. Explicit confirmation asks the user to verify before acting: "You want to transfer two hundred pounds to Sam Patel. Is that right?" It is the safest and the slowest. Used everywhere, it makes a system maddening; users quickly start answering "yes" without listening, which defeats the purpose. Implicit confirmation acts, or proceeds, while stating the interpretation so the user can correct it: "Setting a timer for twelve minutes." The user hears what the system understood and can interrupt or follow up if it is wrong. It costs little time and catches many errors, which is why it is the default for most everyday actions. No confirmation simply acts. It suits actions whose result is self-evident — "play some jazz" is confirmed by the jazz — and actions that are trivial to undo. The choice depends on how likely a misunderstanding is and how much it would cost. Confidence scores from ASR and NLU address the first; the nature of the action addresses the second. An action that is irreversible, costly, or affects other people — sending money, making a purchase, sending a message, unlocking a door — warrants explicit confirmation regardless of confidence. An action that is cheap and reversible can proceed with implicit confirmation even at moderate confidence. Table 2 summarises the common pattern. Table 2. Choosing a confirmation strategy by risk and reversibility. Situation Example Recommended strategy Why Result self-evident, trivially undone Play music; turn on a light None, or brief implicit The outcome itself confirms Low cost, easily changed Set a timer; add milk to a list Implicit Lets user catch errors without slowing them Moderate cost or low recognition confidence Book a table; set an alarm for an unusual time Implicit with key details, or explicit if confidence is low Balances speed against likely error Irreversible, financial or affects others Send money; place an order; send a message; unlock a door Explicit, restating the critical details Cost of error outweighs cost of the extra turn Two refinements make confirmation work better. First, confirm the details that matter, not the whole request. "Two hundred pounds to Sam Patel" is better than reading back a full transaction record. Second, make correction easy without starting over. If the user says "no, three hundred," the system should change the amount and re-confirm, not throw away the whole request. Language-model assistants raise the stakes on confirmation. Because they can take a wider range of actions from a wider range of phrasings, the cost of a misinterpretation rises. The responsible approach is to treat the confirmation policy as a fixed rule outside the model's discretion: certain categories of action always require an explicit yes, regardless of how confident the model appears. Shaping the sound Words on a page are only half of a spoken turn. The other half is how they sound: pace, pauses, emphasis, and pronunciation. Modern text-to-speech voices handle most of this automatically, but not always well, and designers have tools to intervene. The most widely supported is the Speech Synthesis Markup Language (SSML), a W3C standard supported in varying degrees by Alexa, Google's speech services and others. SSML lets a designer insert pauses of a set length, mark words for emphasis, specify how text should be interpreted (as a date, a phone number, individual characters, or a cardinal number), adjust rate, pitch and volume, and give exact pronunciations for names and unusual words. Platforms add their own extensions; Alexa, for instance, offers speaking styles for certain voices. Used sparingly, these tools solve real problems. A short pause before the key piece of information helps it land. Correct reading of a postcode, a flight number or a medication dose can be the difference between usable and dangerous. A carefully specified pronunciation of a brand name or a place name prevents an otherwise good experience from sounding foolish. Used heavily, the same tools produce speech that sounds mannered and robotic. The guiding principle is that markup should correct the voice where it goes wrong, not perform emotion it does not have. Sound can also do work without words. Short audio cues, known as earcons, can signal that the system is listening, that it has finished, that an action succeeded or failed, or that it is working on a long request. A consistent, brief sound when a device starts listening is far more efficient than a spoken "I'm listening". The risk is overuse: a system that chirps at every step becomes as tiring as one that talks too much. A prompt, rewritten Principles become clearer when applied to a real draft. Consider a first-draft prompt from a hypothetical pharmacy assistant, the kind of thing that often emerges when a written web flow is turned straight into speech: "Welcome back to the pharmacy assistant. In order to help you with your prescription needs today, I can refill an existing prescription, check the status of an order that has already been placed, transfer a prescription from another pharmacy, find the opening hours of your nearest store, or speak to a member of our pharmacy team. Please tell me which of these you would like to do, or say 'help' at any time for more options." Read aloud, it runs well over twenty seconds. It names five options, more than a listener can comfortably hold. The most common task — refilling — is first, which is good, but it is preceded by a sentence of throat-clearing. "Prescription needs" is institutional language no customer uses. The closing sentence introduces a sixth option ("help") and ends not with the question but with an instruction about something else. A revision applying this chapter's principles might be: "Welcome back. Do you want to refill a prescription, or something else?" That is about three seconds. It offers the most likely task directly, since for most callers that is the reason they came, and leaves a clear route for everyone else. If the user says "something else", the follow-up can offer the next two or three options: "I can check an order, transfer a prescription, or connect you to the pharmacy team." A returning user who has refilled before might hear an even shorter prompt, or a personalised one: "Welcome back. Do you want to refill your usual prescription?" And a user who instead says "when do you close?" should simply get an answer, since an open system need not force them through a menu at all. Two features of the revision deserve attention. First, it is shorter not because words were trimmed but because decisions were made: the team decided which task is most common, decided that a two-step menu is better than a five-item one, and decided that "help" needs no announcement because it works anyway. Second, the revision reflects what users actually say. A team would know that refills dominate, and that customers say "refill" rather than "prescription needs", only by looking at evidence — call logs, transcripts or research — which is where every good rewrite begins. Numbers, times and things that must be exact A small category of content deserves particular care because errors in it matter: numbers, times, dates, amounts, addresses and codes. Spoken numbers should be phrased the way people say them, not the way they are stored. "Two fifteen in the afternoon" is easier to hear than "fourteen fifteen" for most English-speaking users, though conventions vary by country and the system should follow local norms. "Tuesday the fourteenth" is better than "the fourteenth of the tenth". Prices should be said as people say them: "four ninety-nine" or "four pounds ninety-nine", not "four point nine nine". Long numbers should be broken into the groups people expect — phone numbers in their customary chunks, card numbers in fours — with brief pauses between groups. Relative expressions often help. "Your parcel arrives tomorrow" carries more than "Your parcel arrives on 4 October", because the listener does not have to work out what day that is. But relative expressions must be correct in the user's time zone and must not become ambiguous: "next Friday" means different things to different people, and a system should avoid producing it. Where precision is critical, redundancy is a virtue. A medication assistant should say "Take two tablets — that's two — twice a day", or confirm the key number at the end, because a misheard number here has consequences. This is one of the few places where repetition, normally a fault in voice design, is the right choice. Turn-taking in practice Two practical aspects of turn-taking deserve attention because they are where systems most often feel clumsy. The first is endpointing: deciding when the user has finished speaking. Cut off too early and the system acts on half a sentence — a common irritation when people pause to think mid-request. Wait too long and the interaction feels sluggish. Designers working on modern platforms have limited control here, but they can influence it through prompt design: a question with a short expected answer ("Which size?") naturally produces short, crisp replies, while an open question invites pauses and false starts. The second is barge-in: letting the user interrupt the system. In human conversation, interruption is normal and often cooperative — the listener has already understood and wants to move on. Voice systems that cannot be interrupted force users to sit through prompts they do not need. Most smart speakers let users interrupt with the wake word; some newer, model-based voice modes allow more natural interruption. Where barge-in is possible, designers should front-load content so that users who interrupt early have still heard what matters. Consistency and variation A final question about the single turn is whether it should be the same every time. Human speakers vary their phrasing naturally, and a system that says exactly the same confirmation hundreds of times can feel mechanical. Many design guides have therefore recommended varying common responses, picking randomly among a few equivalent phrasings. Variation helps with social phrases — greetings, acknowledgements, sign-offs — where repetition grates. It hurts where predictability matters. Users learn the shape of important responses and listen for particular words; a confirmation of a payment that changes wording each time is harder to verify at a glance of the ear. The sensible rule is to vary the social wrapping and keep the informational core stable. "Done — I've added milk" and "Okay, milk's on the list" can alternate; the structure of a bank balance should not. Language models vary their phrasing whether or not anyone asks them to, which makes this rule more important, not less. For critical responses — amounts, times, names, warnings — it is often worth using fixed templates rather than letting the model compose freely, so that the user can rely on hearing the same information in the same place every time. The turn is small, but it is where trust is built or lost one sentence at a time. Hashtags: #VoiceUserInterfaces #VUI #ConversationalDesign #SmartSpeakers #VoiceInteraction #SpeechInterfaceDesign #ConversationDesign #WorkingMemory #InvisibleAffordances #IntentRecognition #AutomaticSpeechRecognition #NaturalLanguageUnderstanding #IntentAndSlotModel #LanguageModelOrchestration #DialogueManagement #PromptDesign #ConversationalContext #ErrorRecovery #ExplicitConfirmation #ImplicitConfirmation #SpeechSynthesis #SSML #VoicePersona #AccessibleVoiceDesign #FutureOfVoiceInterfaces

Download the Book (PDF): Introduction Open a browser tab, drag a two-gigabyte video file onto the page, and trim it. A decade ago that sentence described something that could not happen. The browser was a document viewer that had learned to run scripts, and the scripts were JavaScript: flexible, forgiving, and dynamically typed, which made it superb for wiring up interfaces and poor at the sustained, predictable number-crunching that video codecs, physics engines, and image filters demand. Anything serious was a download, an installer, a native application. Today the trimming happens in the tab. A library such as ffmpeg.wasm takes the FFmpeg project, one of the most heavily optimised pieces of C code in existence, and compiles it to WebAssembly so that the same decoders and encoders that run on servers and desktops run inside the page. Adobe ships Photoshop on the web, built from the same C++ code base that has been accumulating since the 1990s. Figma, the design tool that convinced a generation of professionals that a browser could host their primary work application, renders its canvas through C++ compiled to WebAssembly. Google Earth, once a desktop download and then a Chrome-only experiment, runs across browsers on the same foundation. None of these teams rewrote their engines in JavaScript. They recompiled them. That is the first and most important thing to understand about WebAssembly. It is not a new language you are expected to write. It is a compilation target: a compact binary instruction format that a browser can validate, compile, and execute at speeds close to native machine code, inside the same security sandbox that protects you from every other web page. You write C, C++, Rust, Go, or a growing list of other languages; a toolchain turns that code into a .wasm module; and the browser runs it alongside your JavaScript. The argument of this book The popular story about WebAssembly is that it makes the web fast. That story is half true, and the false half causes most of the disappointment teams experience when they adopt it. A WebAssembly module does not make your web application fast in the way that a better CPU does, uniformly and without effort. It makes certain kinds of work fast, under certain conditions, and the conditions are set mostly by decisions you make outside the module. The controlling idea of this book is that WebAssembly pays off when you treat it as a compute engine behind a narrow, deliberate boundary. The engine is the compiled code: tight loops over numbers and bytes, written in a language that gives the compiler something predictable to optimise. The boundary is everything that connects that engine to the rest of the web: how data moves in and out of the module's memory, how often JavaScript and WebAssembly call each other, how threads are created and fed, how the module is downloaded and compiled, and which browser APIs it reaches through JavaScript to touch the screen, the file system, and the network. Teams that succeed with WebAssembly get three things right. They choose a workload where compute, not coordination, is the bottleneck. They choose a source language and toolchain whose costs they understand, because C++ with Emscripten, Rust with wasm-bindgen, and Go with its own runtime produce very different modules with very different trade-offs. And they design the boundary on purpose, moving large blocks of data across it rarely rather than small pieces often, so that the engine spends its time computing rather than waiting. Teams that struggle usually got one of those wrong. They ported a JavaScript-heavy application whose real cost was DOM manipulation, which WebAssembly cannot do directly. Or they compiled a Go program and were surprised by a multi-megabyte binary carrying a garbage collector and scheduler. Or they called into the module thousands of times per frame, passing strings each time, and watched the conversion overhead swallow every gain. The format itself was not the problem in any of these cases. The architecture was. What you will find here The chapters run in a deliberate order. The first explains what WebAssembly actually is: the stack machine, the module structure, linear memory, and the validation and compilation pipeline that lets a browser trust and accelerate code it has never seen. The second confronts the performance question directly, with the best available evidence on how close to native WebAssembly really runs, where it beats JavaScript, and where it does not. The next three chapters take the three languages named on the cover in turn. Chapter 3 covers C and C++ with Emscripten, the oldest and most complete toolchain, and the one behind most of the famous ports. Chapter 4 covers Rust with wasm-bindgen and wasm-pack, which has become the default choice for new code written specifically for WebAssembly. Chapter 5 covers Go, both through the standard Go compiler's browser target and through TinyGo, a separate compiler that trades completeness for much smaller output. Each chapter includes short code listings, because a few lines of real code teach the shape of a toolchain faster than any description. Chapter 6 is the centre of the book's argument: the boundary between WebAssembly and JavaScript, and the techniques for moving data across it without paying for the trip twice. Chapter 7 covers the features that turned WebAssembly from a promising minimum viable product into a platform for professional applications: threads backed by shared memory, SIMD vector instructions, and the set of capabilities standardised as WebAssembly 3.0 in September 2025, including garbage collection, exception handling, and 64-bit memory. Chapter 8 assembles all of this into the architecture of real applications, with video editing and games as the worked cases, and covers the unglamorous work of shipping: download size, caching, debugging, and security. Chapter 9 leaves the browser to look at WASI and the component model, which matter to web developers because they let the same compiled module run on the client, the server, and the edge. What this book leaves out A short book earns its depth by declining breadth, and several worthwhile topics sit outside these pages. WebAssembly frameworks that compile entire user interfaces from C#, through Microsoft's Blazor, or from Kotlin and Dart, through their respective web targets, appear only where they illuminate a general point, such as how garbage-collected languages are adapting to the platform. Writing WebAssembly by hand in its text format is shown once, to make the machine visible, and not taught. Blockchain virtual machines built on WebAssembly, an active area in their own right, are not covered. And the book does not attempt a survey of every language with a WebAssembly compiler, a list that now runs from Zig and Swift to Python interpreters and beyond, because the decisions that matter are the same whichever language produces the module: what runtime it carries, how it crosses the boundary, and what it costs to download. The three languages on the cover were chosen because they span the range of those decisions. C++ represents the vast existing body of native code that WebAssembly was built to bring to the web. Rust represents new code designed for WebAssembly from the start. Go represents the garbage-collected languages, with their runtimes and their trade-offs. A reader who understands how these three behave will be able to evaluate any other toolchain quickly. A note on currency WebAssembly moves quickly. Features described as proposals in articles from 2022 are shipping standards now, and the system interface for running WebAssembly outside the browser went through a major new release in June 2026. This book describes the platform as it stands in the autumn of 2026. Where browser support is uneven, it says so; where a tool's maintenance status has changed, it says that too. The underlying ideas, however, change slowly. A stack machine with a linear memory and a sandboxed boundary is what WebAssembly was in 2017 and what it remains, and the discipline of designing around that boundary will outlast any particular flag or version number. The reader this book has in mind is a working web developer, or a systems programmer curious about the web, who wants to know when WebAssembly is the right tool and how to use it well when it is. You do not need to know C++, Rust, or Go in depth to follow the argument, though familiarity with at least one compiled language will help with the listings. You do need to be willing to think about memory, because in WebAssembly, memory is where the performance lives and where most of the mistakes happen. Chapter 1: What WebAssembly Actually Is Every explanation of WebAssembly eventually reaches for the phrase "assembly language for the web," and every explanation then has to walk it back. WebAssembly is not the assembly language of any real processor. It does not expose registers, it cannot jump to arbitrary addresses, and it cannot read memory outside a region the host has handed it. It is better understood as a virtual instruction set designed under two constraints that pull in opposite directions: it must be low-level enough that a compiler can translate it into fast machine code almost directly, and it must be structured enough that a browser can prove, before running a single instruction, that the code cannot escape its sandbox. The way WebAssembly reconciles those constraints explains nearly everything about how it behaves in practice, including its performance profile, its limitations, and why the boundary with JavaScript matters so much. So it is worth spending a chapter on what is actually inside a .wasm file and what a browser does with it. From asm.js to a binary format WebAssembly did not appear from nowhere. Its immediate ancestor was asm.js, a project from Mozilla around 2013 that defined a strict subset of JavaScript. Code written in that subset used only numbers, stored all its data in a single large typed array, and annotated its types through idioms such as x|0 to force an integer. A C or C++ compiler, specifically the Emscripten toolchain, could emit asm.js, and a JavaScript engine that recognised the subset could compile it ahead of time into efficient machine code rather than treating it as ordinary dynamic JavaScript. Asm.js proved the concept. Games built with Unity and Unreal ran in browsers through it, and Figma's C++ rendering engine shipped as asm.js before WebAssembly existed. But asm.js had a structural problem: it was still JavaScript text. The browser had to download it, parse it as JavaScript, recognise the subset, and only then compile it. For large code bases, parsing alone took seconds. When Figma switched from asm.js to WebAssembly in 2017, co-founder Evan Wallace reported that load time improved by more than three times regardless of document size, and attributed much of the gain to the fact that the binary format parsed around twenty times faster than the equivalent asm.js. The engineers behind the major browser engines (Google's V8, Mozilla's SpiderMonkey, Apple's JavaScriptCore, and Microsoft's Chakra at the time) agreed in 2015 to design a proper binary format together. The minimum viable product shipped in all four major browsers during 2017, and the World Wide Web Consortium published the core specification as an official Recommendation in December 2019. The design was laid out in a 2017 paper by Andreas Haas and colleagues, "Bringing the Web up to Speed with WebAssembly," presented at the PLDI programming languages conference, which remains the clearest statement of the original goals: fast, safe, portable, and compact. A stack machine with structured control flow WebAssembly instructions operate on an implicit stack of values. An instruction such as i32.add pops two 32-bit integers, adds them, and pushes the result. Function parameters and local variables live in numbered slots that instructions read and write explicitly. There are only four basic numeric types in the original design: 32- and 64-bit integers and 32- and 64-bit floating-point numbers. A later addition introduced a 128-bit vector type for SIMD, and reference types for pointing to things outside linear memory. WebAssembly has a text format alongside the binary one, which is useful for seeing what the instructions look like. Here is a complete module that exports a function adding two integers: (module (func $add (export "add") (param $a i32) (param $b i32) (result i32) local.get $a local.get $b i32.add)) The function pushes its two parameters onto the stack, adds them, and leaves the result on the stack as its return value. Compiled to binary, the entire module occupies a few dozen bytes. The stack is a convenience for encoding, not a description of how the code runs. When a browser compiles this function, it does not build a stack in memory and push values onto it. It notices that the two values flow straight into an addition and emits a single machine instruction operating on two registers. The stack form is compact, which keeps downloads small, and it is trivial to verify, because the type of every stack slot at every point in the function can be computed in a single linear pass. The more consequential design choice is structured control flow. Real processors implement loops and conditionals with jumps to arbitrary addresses. WebAssembly has no arbitrary jumps. It has block, loop, and if constructs that nest like the braces in a C program, and branch instructions that can only target an enclosing construct by its depth. A br 0 inside a loop jumps back to the loop's start; inside a block it jumps to the block's end. You cannot express a jump into the middle of another function or into the middle of a data region, because there are no addresses to jump to. This constraint does two jobs. It makes validation fast and simple, because the validator never has to reason about where control might arrive from. And it makes WebAssembly hard to exploit, because a whole class of attacks that depend on redirecting control flow into injected code or into the middle of existing instructions has nothing to work with. Indirect calls, which C++ needs for virtual functions and function pointers, go through a table of function references, and every indirect call checks at run time that the target function has the expected signature. Modules, imports, and exports A WebAssembly program is delivered as a module, and a module is a strongly structured container. Its binary encoding is divided into sections, each with a fixed purpose: a type section listing function signatures, an import section declaring what the module needs from its host, a function section, a table section for indirect calls, a memory section, a global section, an export section declaring what the module offers back, a start function, element and data sections that initialise tables and memory, and a code section containing the function bodies. Custom sections can carry anything else, most commonly debugging information and function names. The import and export sections are where WebAssembly meets the outside world, and they are deliberately minimal. A module cannot do anything that affects its environment except through functions it imports. It has no built-in way to print, open a file, read the clock, draw on a canvas, or make a network request. If it needs any of those things, it declares an import such as a function named log in a namespace named env, and the host must supply a function with that name and signature when it instantiates the module. In a browser, the host is JavaScript. This is the root of the most important practical fact about WebAssembly in the browser: it has no direct access to the DOM or to any Web API. Everything it does beyond pure computation goes through JavaScript. Toolchains hide this to varying degrees by generating JavaScript glue code that wraps the browser's APIs as imports, but the indirection is always there, and its cost shapes good architecture. From JavaScript, loading a module looks like this: const { instance } = await WebAssembly.instantiateStreaming( fetch("add.wasm"), { env: { log: (x) => console.log(x) } } // the import object ); console.log(instance.exports.add(2, 3)); // 5 The distinction between a module and an instance is worth holding onto. A WebAssembly.Module is compiled code, stateless and shareable; it can be cached, sent to a Web Worker, and instantiated many times. A WebAssembly.Instance is that code bound to a particular set of imports and its own memory, tables, and globals. Two instances of the same module share no state unless they are deliberately given the same memory. Linear memory and the sandbox A WebAssembly module's working data lives in linear memory: a single contiguous array of bytes, addressed from zero, that the module can read and write with load and store instructions. Linear memory is sized in pages of 64 kibibytes, starts at a size declared by the module, and can grow on request, up to a maximum. In the original design, addresses were 32-bit integers, so a memory could hold at most four gibibytes. From the compiled program's point of view, linear memory is simply its address space. When C++ code compiled with Emscripten allocates an object with new, the allocator, which is itself compiled to WebAssembly and shipped inside the module, carves the space out of linear memory. The program's stack for local arrays and address-taken variables lives there too, along with static data and the heap. A pointer in C becomes a 32-bit integer offset into this array. From JavaScript's point of view, linear memory is an ArrayBuffer. JavaScript can wrap it in a Uint8Array, a Float32Array, or any other typed array view and read or write the module's memory directly. This shared view is how large amounts of data cross the boundary efficiently: JavaScript writes an image's pixels into the module's memory at an agreed offset, calls an exported function with that offset and a length, and reads the result back from memory when the call returns. Nothing is serialised, and nothing is copied that does not need to be. The sandbox follows from the memory model. Every load and store is checked against the bounds of linear memory, and an access outside those bounds traps: execution stops with an error that JavaScript can catch, rather than reading or corrupting something else. A module can scribble over its own memory as freely as any buggy C program, but it cannot reach the JavaScript heap, the browser's internal structures, or another module's memory. Its code is not in linear memory at all, so it cannot overwrite its own instructions. Its call stack, the one holding return addresses, is managed by the engine and is invisible to the program, so the classic stack-smashing attack that overwrites a return address has no target. These checks sound expensive, and on 64-bit hardware engines have a clever way to make them nearly free. Because 32-bit addresses can never exceed four gibibytes, the engine reserves a full four-gibibyte region of virtual address space for each memory, plus a guard zone, and marks everything beyond the memory's current size as inaccessible. Any out-of-bounds access then lands in unmapped pages and is caught by the processor's own memory protection hardware, which the engine converts into a trap. The compiled code performs no explicit comparison at all. As Chapter 7 explains, this trick is exactly what 64-bit memory loses, and it is why the newer, larger memories run more slowly. It is important to be precise about what the sandbox does not provide. It protects the host from the module. It does not protect the module from itself. A C++ program with a buffer overflow compiled to WebAssembly still has a buffer overflow; it simply cannot use it to escape into the browser. Within its own linear memory, the program can still corrupt its data structures, and an attacker who controls the program's input may still be able to change its behaviour. WebAssembly is a containment boundary, not a memory-safety guarantee for the code inside it. Validation, compilation, and tiering When a browser receives a WebAssembly module, it does three things before running it: it decodes the binary, validates it, and compiles it to machine code. Validation checks that the module is well-formed and type-safe. Every function body is walked once, tracking the types on the value stack, and the validator confirms that each instruction receives operands of the right type, that every branch targets a valid enclosing block with a compatible stack, that every function call matches the callee's signature, and that every memory access names a memory that exists. A module that fails validation is rejected outright. Because the format was designed for it, validation is a single fast pass and can happen while the bytes are still arriving. That last point matters. WebAssembly.compileStreaming and WebAssembly.instantiateStreaming accept a response from fetch and begin decoding, validating, and compiling functions as the bytes stream in over the network. For a large module, compilation can complete almost as soon as the download does. Compare this with JavaScript, which must be fully received and parsed before significant work can start, and with asm.js, which carried all of JavaScript's parsing costs plus its own. Modern engines then use tiered compilation. Chrome's V8 first compiles every function with Liftoff, a baseline compiler that makes one quick pass and produces reasonable machine code very quickly, so the application can start. Functions that turn out to be hot are recompiled in the background by TurboFan, V8's optimising compiler, and swapped in when ready. Firefox's SpiderMonkey follows the same pattern with its own baseline and optimising tiers, and Safari's JavaScriptCore has its own tiers as well. The result is that a large application starts quickly and reaches full speed within moments. Browsers also cache compiled code. Once a module has been compiled and optimised, V8 can store the machine code alongside the cached HTTP response, so that the next visit skips compilation entirely as long as the module has not changed. Adobe's engineers, describing Photoshop's move to the web, reported that combining service worker caching with V8's code caching for WebAssembly and JavaScript cut code initialisation time by seventy-five percent. For a heavy application, caching is the difference between a tool people tolerate and one they open without thinking. Looking inside a module Because the format is so regular, a .wasm file is easy to inspect, and the habit of inspecting the modules your toolchain produces pays for itself quickly. Every module begins with the same eight bytes: the four-byte magic number, which spells a zero byte followed by the letters "asm", and a four-byte version number that has been 1 since the first release. The sections follow in a fixed order, each introduced by an identifier and a length, and integers throughout are stored in LEB128, a variable-length encoding in which small numbers take a single byte. The compactness of WebAssembly comes largely from these choices: instruction opcodes are mostly one byte, local variable indexes are small integers, and nothing is spelled out in text. The WebAssembly Binary Toolkit, known as WABT and maintained under the WebAssembly project, provides the standard tools for reading this format. wasm2wat converts a binary into the text format shown earlier, so you can read exactly what a compiler emitted; wat2wasm goes the other way; and wasm-objdump lists a module's sections, imports, exports, and the size of each function. Running wasm-objdump -x over a freshly built module answers questions that otherwise lead to hours of confusion: whether the function you meant to export is actually exported, which imports the module expects JavaScript to supply, whether the memory is shared or growable, and how large the code section is compared with the data section. The Binaryen project, whose optimiser appears in later chapters, includes complementary tools for analysing and transforming modules. Reading compiled output is also the most direct way to learn what WebAssembly costs. Compile a small C or Rust function with and without optimisation, convert both to text, and the difference is plain: the unoptimised version shuffles values through memory and locals, while the optimised version is a short sequence of arithmetic. Compile a function that takes a string, and the text format reveals the calls to an allocator and the loops that copy bytes. These exercises take minutes and build an intuition for the boundary that no amount of documentation provides. What a module cannot do Holding the design in view makes the limitations easy to predict, and knowing them early saves wasted effort. A module cannot touch the DOM. Everything visible on the page is reached through JavaScript imports, so an application whose cost lies in creating and updating thousands of DOM nodes will not get faster by moving logic into WebAssembly; it will get slower, because every update now crosses the boundary. A module cannot perform blocking input and output in the browser. The web's APIs are asynchronous: a network request returns a promise, and a file read completes later. WebAssembly's original execution model is synchronous: a function runs until it returns. C programs written to call a blocking read and wait for the result have no natural place to wait. Toolchains solve this with techniques described in Chapter 3, including a newer standard called JavaScript Promise Integration, but the mismatch is real and must be designed around. A module does not share JavaScript's garbage-collected heap, at least not in the original design. C, C++, and Rust manage their own memory inside linear memory and never notice. Languages that rely on a garbage collector, such as Go, Java, Kotlin, and C#, historically had to ship their own collector compiled into the module, scanning their own linear memory, which costs download size and cannot cooperate with the browser's collector to free cycles that span both worlds. The garbage collection extension in WebAssembly 3.0 addresses this directly, and Chapter 7 covers what it changes. Finally, a module is only as fast as the code inside it. WebAssembly gives a compiler a predictable target: fixed types, no hidden conversions, no deoptimisation when an object changes shape. That predictability is real and valuable. But a slow algorithm compiled to WebAssembly is a slow algorithm, and code that leans on a language runtime's reflection, dynamic dispatch, or heavyweight standard library carries those costs into the module. The next chapter looks hard at the evidence for what "near-native" actually means, and at the specific conditions under which WebAssembly outruns the JavaScript it sits beside. Chapter 2: Where the Speed Comes From, and Where It Doesn't "Near-native speed" is the phrase that sells WebAssembly, and it is the phrase most likely to mislead the people buying. It is true in a specific and useful sense: well-compiled WebAssembly running a compute-heavy workload often comes within a modest factor of the same code compiled for the processor directly. It is false in the sense many developers hear, which is that moving code into WebAssembly will make a web application several times faster. Sometimes it does. Often it makes no measurable difference. Occasionally it makes things slower. Deciding whether WebAssembly is right for a project starts with understanding which of those outcomes to expect, and why. The answer depends on three comparisons that are easy to blur together: WebAssembly against native code, WebAssembly against JavaScript, and the cost of the work inside the module against the cost of getting data in and out of it. How close to native The most careful published measurement of WebAssembly against native code remains a 2019 study by Abhinav Jangda, Bobby Powers, Emery Berger, and Arjun Guha at the University of Massachusetts Amherst, titled "Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code" and presented at the USENIX Annual Technical Conference. Earlier comparisons had used small benchmark kernels, short functions that fit comfortably in a compiler's optimisation window. Jangda and colleagues built infrastructure that let them run unmodified, full-sized programs from the SPEC CPU benchmark suites in the browser, programs that exercise compilers in the messy ways real applications do. Their headline result was that applications compiled to WebAssembly ran slower than native code by an average of 45 percent in Firefox and 55 percent in Chrome, with peak slowdowns of 2.08 times in Firefox and 2.5 times in Chrome. They traced the gap to specific causes: the engines' code generators produced more instructions and more branches than a mature native compiler, made poorer use of the processor's registers, and paid for safety checks that native code does not perform, including stack overflow checks and indirect call signature checks. Two things should be said about that result. First, it is several years old, and engines have improved since. Tiered compilers have become more sophisticated, SIMD has arrived, and the engines' optimising tiers have had years of tuning against real applications. Second, even a 50 percent overhead is a remarkable outcome for code that is downloaded from an untrusted source, verified, and run in a sandbox across every operating system and processor architecture. The useful framing is not that WebAssembly matches native, but that it runs within a small, predictable factor of native, which is a very different position from where JavaScript stood for the same workloads. It is also worth noting what the study measured: compute-heavy benchmark programs, chosen precisely because they stress the processor. Real applications spend much of their time elsewhere, waiting on input, drawing to the screen, or talking to the network, and in those phases the gap between WebAssembly and native shrinks toward irrelevance because neither is doing much computation. How it compares with JavaScript The comparison developers actually care about is with JavaScript, and here the picture is more interesting than a simple speed ratio. Modern JavaScript engines are extraordinary pieces of engineering. A hot JavaScript function that always receives the same types of values, operates on arrays of numbers, and avoids allocating objects can be compiled by V8's optimising tiers into machine code that rivals what a C compiler would produce. For such code, rewriting it in Rust and compiling to WebAssembly may yield little or no speedup, and benchmarks showing JavaScript matching or even beating WebAssembly on small numerical kernels are easy to find and entirely legitimate. The difference lies in predictability rather than peak speed. A JavaScript engine reaches its best code through speculation. It watches the function run, records the types it sees, and compiles machine code that assumes those types will continue. If the assumption breaks, because a function that always received integers suddenly gets a floating-point number or an object gains a new property and changes its hidden shape, the engine must throw away the optimised code, fall back to a slower tier, and possibly re-optimise later. These deoptimisations are invisible in the source code and can make performance fluctuate in ways that are hard to reproduce, let alone fix. Garbage collection pauses add further variability whenever code allocates. WebAssembly does not speculate, because it does not need to. Its types are fixed in the binary. An i32.add is always a 32-bit integer addition. Memory layouts are decided by the source compiler ahead of time. Allocation, in C, C++, and Rust, happens through a compiled allocator in linear memory, not through the JavaScript garbage collector. The code a browser produces for a WebAssembly function on the first optimisation is roughly the code it will run for the life of the page. For applications that need consistent frame times, such as a game rendering at sixty frames per second or an audio processor that must fill a buffer every few milliseconds, that consistency is worth more than a faster average with occasional stalls. There is a second, quieter advantage. WebAssembly compilers can perform the heavy optimisation work ahead of time. When Emscripten or the Rust compiler builds a module, LLVM spends as long as it needs on inlining, loop transformations, vectorisation, and dead code elimination. The browser's job is then closer to translation than to optimisation. JavaScript engines must do all their optimisation at run time, on the user's device, competing with the application for processor time. For large code bases, the ahead-of-time advantage is substantial. The cases that prove the point The clearest evidence for WebAssembly's real-world performance comes from teams that measured before and after on production applications. Figma's 2017 switch from asm.js to WebAssembly produced the threefold improvement in load time described in the previous chapter. The gain came primarily from faster parsing and compilation, not from faster execution of the rendering code itself, which illustrates that for large applications startup time can matter as much as steady-state throughput. Google Sheets offers an instructive case because the outcome was not immediate. The Sheets calculation engine is written in Java and had for years been compiled to JavaScript, first with Google Web Toolkit and later with the J2CL transpiler, running in a Web Worker. When the team began compiling it to WebAssembly using the new garbage collection extension, their first prototype ran calculations roughly twice as slowly as the JavaScript version. Rather than abandoning the effort, they investigated. Some of the gap came from optimisations that the JavaScript engine had been performing automatically, such as speculative inlining and devirtualisation of method calls, which the WebAssembly toolchain needed to replicate ahead of time; adding them produced a speedup of around 40 percent. Some came from reimplementing in compiled code things the browser already does well: switching regular expression handling from a compiled Java library to the browser's native RegExp made those operations around a hundred times faster. And some came from data structures that had been shaped around JavaScript's quirks. After this work, the WebAssembly version ran calculations approximately twice as fast as JavaScript. Michael Thomas and Thomas Steiner, who wrote up the case for Google's web.dev site, presented it as a fourfold swing from the first prototype. The Sheets story is the best single illustration of this chapter's argument. WebAssembly was not automatically faster. It became faster when the team understood where its advantages lay, stopped fighting the platform for work the browser already did natively, and gave the compiler what it needed. Adobe's account of bringing Photoshop to the web, written by Nabeel Al-Shamma and Thomas Nattestad in 2021, provides a different kind of evidence. Photoshop's image processing relies heavily on Halide, a language for writing high-performance image pipelines, and Adobe reported that WebAssembly SIMD instructions gave a three to four times speedup on average, with some operations seeing speedups of 80 to 160 times. Those are figures for vectorised code against scalar code, not WebAssembly against JavaScript, but they show how much of the "near-native" promise depends on having access to the same hardware features native code uses. Where the gains disappear Against those successes stand the cases where WebAssembly helps little or not at all, and they share recognisable features. The first is work that is not compute. An application that spends its time updating the DOM, laying out text, responding to events, or waiting on network requests is bound by the browser's own machinery, not by the speed of the application's logic. WebAssembly cannot speed up the browser's layout engine, and because it must call through JavaScript to modify the page, putting DOM-heavy logic in a module adds a crossing cost to every operation. Frameworks that compile Rust or C# user interfaces to WebAssembly exist and work, but their selling point is the language and the shared code, not raw speed in rendering interfaces. The second is chatty boundaries. Calling an exported WebAssembly function from JavaScript is cheap in modern engines, comparable to calling a JavaScript function, as long as the arguments are numbers. The cost arrives with everything else. Strings must be encoded into bytes, copied into linear memory, and decoded on the way back. Objects must be flattened into memory layouts or represented as handles. If a design makes thousands of small calls per frame, each passing a string or an object, conversion overhead can dominate the actual work. Chapter 6 is devoted to designing around this, but the principle is simple: a module should receive a large job, work on it without interruption, and return a result. The third is startup and size. A WebAssembly module carrying a large language runtime, a garbage collector, or a heavy standard library may take longer to download and compile than the JavaScript it replaces would take to run. For a calculation that executes once on page load and takes ten milliseconds in JavaScript, adding a two-megabyte module that takes a second to arrive on a mobile connection is a straightforward loss. WebAssembly earns its download when the work it does is large, repeated, or both. The fourth is code that was already fast. If a JavaScript function is simple, numerically typed, and stable, the engine is probably already compiling it well. Rewriting it may produce a small gain or none, and the cost in build complexity and boundary management is real. Choosing workloads Taken together, the evidence gives a usable rule. WebAssembly helps most when the work is computationally heavy, runs for long enough or often enough to amortise download and compilation, operates on large blocks of numerical or binary data that can stay inside linear memory, and benefits from consistent performance. It helps least when the work is dominated by interaction with the browser, involves frequent fine-grained exchanges with JavaScript, or runs once and briefly. It also helps, independently of speed, when the code already exists. Many of the most important WebAssembly deployments are not primarily about performance at all. They are about reuse: bringing a mature C++ engine, a Rust library, or a codec into the browser without rewriting and revalidating hundreds of thousands of lines. Photoshop, AutoCAD's web application, and Google Earth are as much portability stories as performance stories. Being able to run the same tested code on the desktop and on the web is worth a great deal even when the browser version is somewhat slower. The typical workloads sort themselves along these lines, as Table 1 summarises. Table 1. Where WebAssembly helps and where it does not. Workload Main cost Typical WebAssembly benefit Example Video and audio codecs Sustained arithmetic on large buffers High ffmpeg.wasm Image filters and processing Pixel loops, vectorisable High, especially with SIMD Photoshop on the web 2D and 3D rendering engines Scene logic plus GPU submission High for engine logic Figma, Google Earth Physics and game simulation Predictable per-frame compute High, steady frame times Unity web builds Spreadsheet and data engines Calculation over large models Moderate to high Google Sheets calc worker DOM-heavy interfaces Browser layout and rendering Low or negative Typical forms and dashboards Small one-off calculations Download and compile time Usually negative Simple validation logic Measuring honestly A final caution concerns benchmarks. WebAssembly performance claims circulate widely, and many are built on microbenchmarks that measure a single tight loop in isolation. Such numbers say little about a real application, where the costs of loading, crossing the boundary, allocating, and waiting on the browser determine what users experience. The only benchmark that reliably predicts the value of WebAssembly for your application is a prototype of your application's hot path, compiled with your intended toolchain, measured in the browsers your users run, including the boundary crossings it will actually make. Building that prototype well requires care at several points, and each is a place where published comparisons commonly go wrong. Start with a fair JavaScript baseline. Comparing an optimised Rust function against a naive JavaScript one measures the programmer, not the platform. The JavaScript version should use typed arrays rather than ordinary arrays for numerical data, avoid allocating objects inside the hot loop, and keep its functions monomorphic, always called with the same argument types. If careful JavaScript is nearly as fast as WebAssembly for your hot path, that is valuable knowledge: it means you can avoid an entire toolchain. Account for tiering. Both JavaScript and WebAssembly start in baseline tiers and move to optimised code as functions become hot. A measurement taken on the first call captures baseline performance, which may be what users experience for a function called once, or may be wildly unrepresentative for one called every frame. Measure both the first run and steady state after a warm-up period, and report them separately. Measure the whole operation, not just the call. For the greyscale filter used in the next two chapters, the honest measurement starts when the pixels are available in JavaScript and ends when the processed pixels are back in a form JavaScript can use. It includes allocation in linear memory, the copy in, the computation, and the copy out. Timing only the exported function hides the boundary costs that Chapter 6 shows can dominate. Run the measurement at realistic data sizes too, since a filter that wins on a 4K image may lose on a thumbnail, where fixed costs outweigh the per-pixel advantage. Measure on the devices users have. A developer's desktop with a fast processor and plenty of memory is the least representative device most applications will run on. Mid-range Android phones, older laptops, and tablets show different ratios between JavaScript and WebAssembly, between computation and download, and between main-thread and worker execution. Mobile browsers also impose tighter memory limits, which a large module or a large linear memory may hit long before it troubles a desktop. Include load time in the decision. A module's download and compilation cost should be measured on a throttled network and with a cold cache, then compared against the time the module saves over a typical session. For a tool used for hours, a few hundred milliseconds of extra start-up is irrelevant. For a page that runs a calculation once, it may be the whole story. Finally, repeat in every browser that matters. The engines differ in their compilers, their tiering strategies, and their boundary costs, and the ranking of two implementations can change between Chrome, Firefox, and Safari. The UMass study described earlier found different average slowdowns in Firefox and Chrome for the same programs; your application will show differences of its own. None of this is unusual engineering discipline. It is simply what measuring performance always requires. But WebAssembly attracts enthusiasm, and enthusiasm is the enemy of measurement. A team that builds an honest prototype before committing will either confirm that WebAssembly is worth its costs, with numbers to justify the decision, or discover cheaply that it is not. The chapters that follow give you what you need to build that prototype in each of the three main languages. Chapter 3: C and C++ with Emscripten Most of the WebAssembly applications that made people take the technology seriously were written in C or C++, and most of them were compiled with Emscripten. That is not an accident of history. The world's stock of high-performance software, from codecs and physics engines to CAD kernels and image processing libraries, is overwhelmingly written in those two languages, and Emscripten was built from the start to bring that stock to the web with as few changes as possible. Emscripten began as Alon Zakai's personal project at Mozilla around 2010, compiling C and C++ to JavaScript, and it produced asm.js before WebAssembly existed. When WebAssembly arrived, Emscripten became its most complete toolchain. Today it uses LLVM's upstream WebAssembly backend through Clang to generate the module itself, and adds the thing that makes it distinctive: a large runtime layer, partly compiled C and partly JavaScript, that emulates the environment a C program expects. Files, a heap, threads, OpenGL, SDL, sockets, a main loop, and the C standard library are all provided, mapped as faithfully as the browser allows onto Web APIs. That emulation layer is both Emscripten's great strength and the thing developers must learn to manage. A program that calls fopen, draws with OpenGL ES, and runs a while loop at its core can often be compiled for the browser with modest changes. But every piece of emulation costs code size and imposes assumptions, and understanding which pieces you are pulling in is the difference between a lean module and a bloated one. The basic workflow Emscripten's compiler driver is emcc, a drop-in replacement for gcc or clang. Compiling a single file produces either a standalone .wasm file or, more commonly, a .wasm file plus a JavaScript file that loads it, supplies its imports, and exposes its exports. The JavaScript file is the glue: it instantiates the module, implements the system calls the C library makes, and creates a Module object through which your application talks to the compiled code. Consider a function that converts an image to greyscale, the kind of tight pixel loop that suits WebAssembly well: #include #include extern "C" { EMSCRIPTEN_KEEPALIVE void grayscale(uint8_t* pixels, int length) { for (int i = 0; i < length; i += 4) { uint8_t y = (pixels[i] 77 + pixels[i + 1] 150 + pixels[i + 2] * 29) >> 8; pixels[i] = pixels[i + 1] = pixels[i + 2] = y; } } } Two details deserve attention. The extern "C" block prevents C++ name mangling, so the function appears under a predictable name. The EMSCRIPTEN_KEEPALIVE macro tells the compiler and linker that this function is used from outside, which matters because Emscripten aggressively removes code that nothing appears to call. Without it, or without listing the function in the linker's exported functions setting, an optimised build would simply delete it. The build command sets a handful of options: emcc -O3 grayscale.cpp -o grayscale.js \ -sEXPORTED_FUNCTIONS=_grayscale,_malloc,_free \ -sEXPORTED_RUNTIME_METHODS=HEAPU8 \ -sMODULARIZE -sEXPORT_ES6 -sALLOW_MEMORY_GROWTH -O3 asks for full optimisation, which matters far more for WebAssembly than many developers expect; an unoptimised build can be several times larger and slower. The exported functions list includes malloc and free so that JavaScript can allocate space in linear memory, and C function names carry a leading underscore. HEAPU8 exposes a byte view of linear memory to JavaScript. MODULARIZE and EXPORT_ES6 wrap the output as an ES module with a factory function rather than a global, which is what any modern bundler expects. ALLOW_MEMORY_GROWTH lets the heap expand beyond its initial size. Calling the function from the page follows the pattern described in Chapter 1: allocate space in linear memory, copy the data in, call the function with a pointer, and copy the result out. import createModule from "./grayscale.js"; const Module = await createModule(); const image = ctx.getImageData(0, 0, width, height); const len = image.data.length; const ptr = Module._malloc(len); Module.HEAPU8.set(image.data, ptr); // copy pixels into linear memory Module._grayscale(ptr, len); image.data.set(Module.HEAPU8.subarray(ptr, ptr + len)); Module._free(ptr); ctx.putImageData(image, 0, 0); This small example already contains most of the lessons of the boundary. The pointer is just a number. The copy in and the copy out are explicit. The call itself passes only integers. And there is a subtle trap: because the build allows memory growth, any allocation inside the module can replace the ArrayBuffer behind linear memory with a larger one, which detaches every typed array view created over the old buffer. Code that caches Module.HEAPU8 in a local variable across calls into the module can end up writing to a stale view. Reading the property fresh after each call, as above, avoids the problem. Chapter 6 returns to this hazard because it catches experienced developers regularly. Talking to JavaScript: ccall, cwrap, and Embind Raw exports work well for functions that take and return numbers. For anything richer, Emscripten provides several levels of help. The simplest are ccall and cwrap, runtime helpers that call a C function by name and convert JavaScript strings and arrays to and from linear memory automatically. cwrap returns a reusable JavaScript function, so const greet = Module.cwrap("greet", "string", ["string"]) produces a function that accepts and returns JavaScript strings while the helper handles allocation, UTF-8 encoding, and cleanup behind the scenes. These helpers are convenient for occasional calls and wasteful for frequent ones, since every call allocates and copies. For C++ code with classes, Emscripten's Embind library is the main tool. You describe in C++ which classes, methods, functions, enums, and value types should be visible to JavaScript, and Embind generates the glue: #include using namespace emscripten; class Counter { public: explicit Counter(int start) : n(start) {} void increment() { ++n; } int value() const { return n; } private: int n; }; EMSCRIPTEN_BINDINGS(counter_module) { class_("Counter") .constructor() .function("increment", &Counter::increment) .function("value", &Counter::value); } Built with -lembind, the module exposes Module.Counter as a JavaScript class. JavaScript can write const c = new Module.Counter(5); c.increment(); c.value(); and work with the object naturally. Embind also maps std::string to JavaScript strings, std::vector to registered vector types, and supports passing JavaScript callbacks into C++ through its val type, which represents an arbitrary JavaScript value from the C++ side. There is one obligation that Embind cannot remove. A Counter created this way lives in linear memory, and JavaScript's garbage collector does not know about it. When JavaScript is finished with the object, it must call c.delete() to run the C++ destructor and free the memory. Forgetting to do so leaks memory inside the module, and because linear memory never shrinks, a long-running application that leaks steadily will eventually run out. This manual lifetime management across the boundary is one of the genuine costs of C++ interop, and wrappers that take responsibility for it should be part of any serious design. Emscripten also allows inline JavaScript inside C code through the EM_JS and EM_ASM macros, which is useful for small calls to browser APIs that would not justify a separate binding, and a WebIDL binder for describing larger interfaces declaratively. In practice, teams tend to settle on Embind for object-oriented APIs and plain exported functions with explicit memory management for performance-critical paths. Emulating a desktop: files, loops, and graphics Where Emscripten earns its reputation is in porting whole applications rather than individual functions. Three areas of emulation matter most. The first is the file system. C programs expect to open files, and the browser offers no ordinary file system. Emscripten provides a virtual file system that the C library's file functions operate on. By default it is an in-memory file system, so files written during a session vanish when the page closes. Assets can be bundled at build time with --preload-file, which packs a directory into a data file that is downloaded and mounted before the program starts. Other backends persist data to IndexedDB, and Emscripten's newer file system implementation, WasmFS, can sit on top of the Origin Private File System, a browser API that gives each site a private, fast, file-like storage area. Photoshop's web version relies on the Origin Private File System to move document data between disk and memory dynamically, effectively standing in for the memory mapping that the desktop application uses to handle images larger than available RAM. The second is the main loop. A desktop game or graphics program typically runs an infinite loop: read input, update state, draw a frame, repeat. A browser page cannot do this, because the page's main thread must return control to the browser regularly or the tab freezes and nothing gets painted. Emscripten's answer is emscripten_set_main_loop, which takes the body of the loop as a callback and arranges for the browser to call it once per frame through requestAnimationFrame. Restructuring a program around this callback is usually the single largest change needed to port an interactive application. The third is graphics. Emscripten translates OpenGL ES 2.0 and 3.0 calls into WebGL 1 and WebGL 2 respectively, which works because the WebGL standards were themselves modelled on OpenGL ES. It provides ports of SDL2 and other common libraries for windowing, input, and audio. Bindings for WebGPU, the newer, lower-level graphics and compute API now available across major browsers, are also available for applications that want modern GPU access. A game engine that already targets mobile OpenGL ES can often bring its renderer to the web with relatively little change. The synchronous program in an asynchronous world The hardest porting problem is not graphics or files. It is blocking. A C program that calls read on a network socket, or sleep for a hundred milliseconds, or waits for a user to choose a file, expects its thread to pause until the result is ready and then continue from the next line. Web APIs do not work that way. They return promises or invoke callbacks, and the code that requested the operation must return to the browser's event loop before the result can arrive. Emscripten has offered two solutions over the years, and the newer one is now practical. The older solution is Asyncify. Enabled with -sASYNCIFY, it transforms the compiled WebAssembly so that any function on a path that might need to wait can unwind its entire call stack, saving each frame's local state into linear memory, return to the browser, and later rewind the stack to exactly where it was when the asynchronous result arrives. The transformation is clever and it works, but it adds code to every affected function, which increases size and slows execution, and it requires telling the toolchain which imports may suspend. The newer solution is JavaScript Promise Integration, a WebAssembly standard proposal that lets the engine itself suspend a WebAssembly computation when it calls an imported JavaScript function that returns a promise, and resume it when the promise settles. Because the engine manages the suspension, no transformation of the compiled code is needed. JSPI shipped in Chrome 137 and Firefox 139 during 2025, and Emscripten supports it through the -sJSPI setting. Safari support had not arrived at the time of writing, so applications that must run everywhere still need Asyncify or a design that avoids blocking. Where JSPI is available, it removes one of the oldest obstacles to porting synchronous code. The third solution, and often the best, is to avoid the problem by running the blocking code on a Web Worker. Workers can use some synchronous APIs that the main thread cannot, including synchronous access handles in the Origin Private File System, and a worker that blocks does not freeze the page. Emscripten's thread support, covered in Chapter 7, builds on this. Controlling size and catching bugs Emscripten's defaults favour compatibility: they include enough of the runtime that a typical C program works without adjustment. For a production module, the right approach is to start from those defaults and then remove what the application does not use, measuring the effect of each change. Several settings make large differences. -sENVIRONMENT=web,worker tells Emscripten that the module will only run in browsers and workers, so the glue code can drop its support for Node.js and other shells. -sFILESYSTEM=0 removes the virtual file system entirely for code that never touches files, which is common for libraries that operate purely on buffers passed in by JavaScript. -sMALLOC=emmalloc replaces the default allocator, a port of the well-known dlmalloc, with Emscripten's own smaller allocator, which trades some performance under heavy allocation for a smaller binary. -Oz optimises aggressively for size, and --closure 1 runs the Closure Compiler over the generated JavaScript glue to minify it. Disabling C++ exceptions with -fno-exceptions, where the code base permits it, removes the substantial code that exception support requires; for code bases that rely on exceptions, the native WebAssembly exception handling described in Chapter 7 is far leaner than the older JavaScript-based emulation. At the other extreme, -sSTANDALONE_WASM produces a module that does not depend on Emscripten's JavaScript glue at all, importing only a minimal set of system functions in the form defined by the WebAssembly System Interface. Such a module can run in standalone runtimes as well as browsers, though using it in a page then requires writing or generating your own small loader. The C++ standard library deserves particular scrutiny. Including iostream pulls in locale support, formatting machinery, and static initialisers that can add a surprising amount of code. Replacing stream output with printf, or removing logging from release builds, is often one of the cheapest size reductions available. Templates multiply code just as Rust generics do, and heavy template libraries that are free on the desktop can become visible in a download. Emscripten also provides strong tools for finding bugs before they reach users, which matters because, as Chapter 1 explained, memory corruption inside the sandbox is contained but not prevented. Building with -sASSERTIONS enables runtime checks in the glue code that catch common mistakes, such as calling an export before the module has finished initialising, and produces readable error messages. -sSAFE_HEAP instruments memory accesses to detect unaligned and null-pointer accesses. Most powerfully, Emscripten supports Clang's AddressSanitizer through -fsanitize=address, which detects buffer overflows, use-after-free errors, and memory leaks as the program runs in the browser, and UndefinedBehaviorSanitizer through -fsanitize=undefined. Running a port's test suite under the sanitisers is the single most effective way to find the latent memory bugs that every large C++ code base contains, and it is better to find them in a debug build than to have an attacker find them through a malicious input file. Testing should cover the browser configuration as well as the code. A module that works in a Node.js test harness may still fail in a page because of a missing cross-origin isolation header, a server that sends the wrong content type, or a memory limit on a mobile device. Automated browser tests, driven by tools such as Playwright or Puppeteer against real Chrome, Firefox, and WebKit builds, catch these failures before users do. What large ports teach The large C++ ports that have shipped share a set of lessons. Google Earth is one of the longest-running. It first came to the browser in 2017 using Native Client, a Chrome-specific technology for running sandboxed native code that WebAssembly was designed to replace. Google then rebuilt the web version on WebAssembly, and by 2020 it ran in Firefox, Edge, and Opera as well as Chrome. The journey shows both why WebAssembly matters, since Native Client was never going to be adopted by other browsers, and how long it takes for a large native code base to move fully onto a portable standard. Photoshop is the most complex. Adobe's engineers described working with the Chrome and Emscripten teams to improve the toolchain itself, including support for C++ exceptions, which Photoshop's code relies on for error handling, and for dynamic multithreading, since much of Photoshop's performance depends on running work across cores. Some of those improvements went into the WebAssembly standard rather than just the tooling. A port at that scale is not only a consumer of the platform but a driver of it. Autodesk has described compiling decades-old AutoCAD C++ code with Emscripten for its web application, a reminder that one of WebAssembly's most valuable properties is that it allows organisations to preserve their investment in proven engines rather than rewriting them. Across these projects, three practices recur. Teams keep the engine in C++ and write the user interface in web technologies, rather than trying to compile a native interface toolkit. They invest heavily in reducing download size, through optimisation settings, by stripping unused features, and by splitting rarely used functionality into modules loaded on demand. And they treat the boundary between the C++ engine and the JavaScript interface as an API to be designed, with coarse-grained calls and well-defined ownership of memory, rather than as an incidental detail. Emscripten remains the right default for existing C and C++ code. For new code written specifically to run as WebAssembly, many teams now reach for a different language, one designed around memory safety and with a WebAssembly toolchain built around generating precise bindings rather than emulating a desktop. The next chapter turns to Rust. Hashtags: #WebAssemblyInAction #WebAssembly #HighPerformanceWebApplications #WasmModules #CompilationTarget #NearNativePerformance #LinearMemory #WebAssemblySandbox #JavaScriptInterop #BoundaryDesign #Emscripten #RustAndWebAssembly #GoAndWebAssembly #WebAssemblyThreads #SharedMemory #SIMD #WebAssemblyGC #Memory64 #WebAssemblyStreaming #WebWorkers #WASI #ComponentModel #BinaryInstructionFormat #ComputeIntensiveWorkloads #FutureOfWebAssembly

Download the Book (PDF): Introduction A link is the most underrated piece of technology in virtual reality. Consider what it normally takes to put someone inside a virtual space. They need a headset, which is the obvious part. Then they need an account on that headset's platform, a store listing for your application, a download measured in hundreds of megabytes or several gigabytes, an installation step, a set of permission prompts, and, if you are unlucky, an update the first time they launch it. Each of those steps is a door through which a fraction of your audience walks away. For a game that people have already decided to buy, the friction is tolerable. For a furniture showroom that a customer heard about thirty seconds ago, a chemistry lab a teacher wants thirty students to visit before the bell rings, or a museum exhibit someone found by scanning a code on a wall, it is fatal. The immersive web removes nearly all of it. A person wearing a headset opens the browser, follows a link, presses a button that says "Enter VR", and is standing in your space. The same link, opened on a laptop, shows a three-dimensional scene they can orbit with a mouse. Opened on a phone, it shows the same scene, steered with a thumb or by moving the device. Nothing was installed. Nothing was approved by a store. If you fix a bug at eleven in the evening, every visitor the next morning gets the fix, because there is no old version sitting on anyone's device. That is the whole proposition of WebXR, and it is the argument of this book: the distinctive value of building virtual reality for the browser is reach and immediacy, and good WebXR development is the discipline of protecting that value — designing for the weakest device that might open your link, for the first thirty seconds of a visitor's attention, and for every kind of screen rather than only the headset. Developers who treat the browser as a lesser runtime for an app they would rather have built natively tend to produce something that is worse than the native version and fails to exploit what the web does well. Developers who treat the link as the product produce experiences that a native app could not match on its own ground: instant to open, trivial to share, indexable, embeddable, and updated for everyone at once. What has changed For several years that proposition was more promise than practice. The early immersive web ran on a draft standard called WebVR that was never finished, on browsers that supported it behind flags, and on headsets tethered to gaming computers. Plenty of brilliant demonstrations were made; few of them were still running two years later. The picture now is different in ways that matter to anyone deciding where to spend effort. The WebXR Device API, which replaced WebVR, has been shipping in Chromium-based browsers since late 2019, and the World Wide Web Consortium's Immersive Web Working Group continues to maintain it as a Candidate Recommendation, the stage at which a specification is considered technically complete and in implementation. The standalone headset, which needs no computer, became the normal form of consumer VR, and its built-in browser supports WebXR as a first-class feature. Apple's Vision Pro, after an initial period with WebXR hidden behind a developer setting, enabled it by default in visionOS 2 and introduced a new input model to the standard so that its look-and-pinch interaction could work on the web. Google and Samsung's Galaxy XR headset, launched in October 2025 on the Android XR platform, ships Chrome with WebXR support. Every major browser engine now supports WebGPU, the modern successor to WebGL for drawing graphics, and the dominant JavaScript 3D library, Three.js, has added WebXR support to its WebGPU renderer. None of this means the immersive web is finished or that every device behaves the same. It does not, and much of this book is about the differences. But it does mean the foundations are stable enough to build on with a reasonable expectation that what you build this year will still open next year. Who this book is for This book is written for developers who know their way around the web — who can write JavaScript, understand what happens when a page loads, and have perhaps built something with a framework — but who have not built for a headset. It is also written for the technical leads, producers and educators who commission such projects and need to understand what they are asking for, what it will cost in effort, and where the risks lie. You do not need prior experience with 3D graphics. The concepts that matter, such as scene graphs, coordinate spaces, draw calls and frame budgets, are explained when they first become necessary. It is not a reference manual. The interfaces of Three.js, A-Frame and the WebXR Device API are documented thoroughly by their maintainers, and they change: Three.js issues a new release every couple of months, and any line-by-line tutorial printed today will be slightly wrong within a year. What changes much more slowly is the shape of the problem — how an immersive session is structured, why frame rate is a hard constraint rather than a nice-to-have, what makes people feel ill, which architectural choices age well and which do not. That is what this book concentrates on. Where it names specific interfaces, it does so to anchor the explanation in something real, and you should check the current documentation before relying on any particular signature. How the book is organised The first chapter sets out what the immersive web actually is in 2026: what the standard covers, which devices and browsers support it, and what a URL gives you that an app store does not. The second opens the hood on a WebXR session — how a page asks for permission to take over a headset's displays, how the browser hands it a pose sixty to one hundred and twenty times a second, and how it is expected to draw two slightly different images in response. Understanding this layer, even if you never write against it directly, makes every framework above it easier to reason about. The third and fourth chapters cover the two tools most developers will actually use. Three.js is a general-purpose 3D library with a mature WebXR integration, giving you control at the cost of writing more code. A-Frame, built on top of Three.js, lets you describe a scene in HTML-like markup and attach behaviour through reusable components, trading some control for a dramatically faster start. The chapters are written so that you can choose between them, or use both, with clear eyes. The fifth chapter is about the constraint that dominates every other decision: performance. A headset that cannot keep up with its display's refresh rate does not merely look choppy; it makes people sick. The chapter explains where the time goes in a frame, how 3D assets should be prepared for the web, and which levers buy the most headroom. The sixth turns to people rather than pixels: how visitors move, point, grab and read in a virtual space, how to keep them comfortable, and how to make the experience usable by people with different bodies and abilities. The seventh and eighth chapters apply all of this to the two kinds of project named in this book's subtitle. A virtual showroom is a commercial space whose job is to make a product legible and desirable at true scale. An educational simulation is a learning environment whose job is to let students do something they otherwise could not, and to show a teacher what they did. The two share a technical foundation but differ sharply in what success looks like, and working through each in detail shows how the general principles become specific decisions. The ninth chapter is about shipping: testing across devices you may not own, delivering gracefully to visitors who have no headset at all, hosting and caching, and building something that will still work after the people who made it have moved on. The conclusion draws out what follows from all of this for teams deciding whether, and how, to build for the immersive web. A note on words The vocabulary of this field is unsettled, and it helps to fix a few terms at the outset. Virtual reality, or VR, means an experience that replaces the user's view of the world with a rendered one. Augmented reality, or AR, overlays rendered content on a view of the real world, either through a phone's camera or a headset's cameras or transparent lenses. Mixed reality is used by different companies to mean different things and is avoided here. XR is the umbrella term covering all of these, and is where WebXR takes its name. Immersive describes a session in which the browser hands a page exclusive control of the headset's displays, as opposed to inline content drawn inside an ordinary web page. This book concentrates on virtual reality, because that is where showrooms and simulations most often begin and because the techniques are the foundation for everything else. Augmented reality on the web uses the same API with additional modules, and where its differences matter, they are noted. One last point before beginning. The immersive web is unusually forgiving of experiments and unusually unforgiving of carelessness. It costs almost nothing to put a scene on a URL and send it to a colleague; it costs a great deal, in reputation and in visitors' comfort, to ship an experience that stutters, that strands someone without a way out, or that silently fails on the device they happen to own. The rest of this book is an attempt to make the first part easy and the second part rare. Chapter 1: The Immersive Web in 2026 Every virtual reality experience has to solve the same two problems. It has to know where the user's head is, many times a second, and it has to draw what the user would see from there, separately for each eye, fast enough that the world appears to stay still as the head moves. Native VR applications solve these problems by talking directly to the headset's runtime, the system software that tracks the device and composes images onto its displays. A web page cannot talk to that runtime directly; browsers exist precisely to stop arbitrary pages from reaching into the hardware. The WebXR Device API is the negotiated settlement: a narrow, permissioned channel through which a page can ask for tracking data and a place to draw, and through which the browser can say yes, no, or only some of that. Understanding WebXR as a settlement between a page and a browser, rather than simply as "VR in JavaScript", explains most of its character. It explains why a page cannot enter VR without the user pressing something. It explains why the API exposes poses and views rather than raw sensor data, and why some capabilities, such as hand tracking, must be requested explicitly and may be refused. And it explains why the same page can behave differently on different devices: each browser is entitled to decide what it is willing to offer. From WebVR to WebXR The first attempt at this settlement was WebVR, begun around 2014 by engineers at Mozilla and Google who were experimenting with the Oculus Rift development kits of the time. WebVR exposed a headset to a page as a display device with a pose, and it worked well enough to inspire a wave of experiments. But it had been designed around a particular generation of hardware — a tethered headset with a fixed set of controllers — and it adapted badly as the hardware changed. It had no clean way to describe augmented reality, phones used as viewers, or devices whose capabilities differed. WebVR never became a finished standard, and by 2018 the community had decided to replace it rather than extend it. The replacement, WebXR, was designed from the beginning to be device-agnostic. Instead of describing a display, it describes a session: an agreement, for a limited period, that the page will render content for an XR device in a particular mode. Instead of assuming a fixed controller layout, it describes input sources that can come and go and that advertise what they are. Instead of assuming a room of known size, it asks the page to choose a reference space that matches what the experience needs and lets the browser say which are available. Google Chrome shipped the core API in version 79 in December 2019, and the other Chromium-based browsers, including the one built into Meta's headsets, followed. The core specification, maintained by the W3C Immersive Web Working Group, defines three session modes. inline is for content drawn inside an ordinary page, with no exclusive access to a headset. immersive-vr gives the page exclusive control of the headset's displays and replaces the user's view of the world. immersive-ar is defined in a separate AR module and blends rendered content with the real world. A family of further modules adds capabilities on top: hand tracking, hit testing against real surfaces, anchors, compositor layers, lighting estimation, depth sensing, and others. Not every browser implements every module, and this layered design is deliberate. It lets the core be stable while new capabilities are explored, and it lets a browser on a device without, say, depth sensors simply decline that feature. Two security requirements run through the whole specification and shape every WebXR application. The first is that the API is only available in a secure context, meaning the page must be served over HTTPS (or from localhost during development). The second is that requesting an immersive session requires transient user activation: the request has to happen in direct response to something the user did, such as clicking a button. A page cannot throw a visitor into VR on load. This is why every WebXR experience, whatever framework built it, presents an "Enter VR" button, and why that button is not a stylistic choice you can design away. The device landscape The practical question for any developer is which devices and browsers will open their link, and what each will offer. The answer in 2026 is broader than it has ever been, but uneven. Meta's Quest headsets remain the largest installed base of standalone VR devices, and their built-in browser, based on Chromium, has supported WebXR for years and tends to implement new modules early. It supports both immersive VR and immersive AR sessions, the latter using the headset's colour passthrough cameras; it supports tracked controllers and hand tracking; and it supports WebXR layers, which let certain content, such as text panels and video, be composited by the system at higher quality than the page could achieve by drawing it itself. For most teams the Quest browser is the reference device: if an experience runs well there, it is in good shape. Apple's Vision Pro took a more cautious path. At launch in early 2024, WebXR in its Safari browser was available only by enabling a developer setting. Apple used that period to work with the standards group on an input model suited to its headset, which has no controllers and uses eye gaze plus a finger pinch as its primary interaction. The result, called transient-pointer, was introduced in the WebKit team's March 2024 announcement and is now part of the WebXR input specification. When the user pinches, a temporary input source appears, its pointing ray initially aimed along the user's gaze but then following the movement of their hand; when the pinch ends, the input source disappears. Crucially for privacy, the page never sees where the user is looking except at the instant of a deliberate pinch. With visionOS 2, released in 2024, WebXR became enabled by default for immersive VR sessions. Pages can additionally request full hand tracking, which exposes the joints of each hand continuously. Google and Samsung's Galaxy XR, launched on 22 October 2025 as the first headset on the Android XR platform, brought a third major platform. Its version of Chrome supports WebXR, and Google has positioned the platform around open standards — OpenXR for native applications, WebXR for the web. Because Android XR's Chrome shares its engine with desktop and Android Chrome, it inherits much of their WebXR implementation. Beyond headsets, Chrome on Android phones supports immersive AR sessions, which place virtual objects in the camera view, and this is a large audience for showroom-style experiences. Desktop Chrome and Edge support immersive VR when a PC headset is connected through an OpenXR runtime. Other headset makers, such as Pico, ship Chromium-based browsers with WebXR support. The open-source Wolvic browser, which grew out of Mozilla's discontinued Firefox Reality, serves several headsets as well. There are gaps worth naming plainly. Safari on iPhone and iPad does not offer WebXR immersive sessions; a visitor on an iPhone sees whatever non-immersive version of your scene you provide. Desktop Firefox has not shipped WebXR by default. And within the browsers that do support WebXR, the set of optional modules varies. Table 1 summarises the main platforms a typical project will meet. Table 1. Major platforms a WebXR project will encounter in 2026. Platform Browser Immersive modes Primary input Meta Quest headsets Meta's Chromium-based browser VR and AR (passthrough) Controllers, hand tracking Apple Vision Pro Safari (visionOS 2 and later) VR Gaze-and-pinch (transient-pointer), hand tracking Galaxy XR (Android XR) Chrome VR and AR Hand tracking, controllers Android phones Chrome AR Touch on screen Desktop with PC headset Chrome, Edge VR Controllers via OpenXR iPhone, iPad, most laptops Any None (inline only) Touch, mouse, keyboard The last row is the one most projects underestimate. In almost every real deployment, the majority of people who open the link will not be wearing a headset. They will be on a phone, having tapped the link in a message, or on a laptop, having clicked it in an email. What they see decides whether the project's reach is a strength or an embarrassment. This theme returns throughout the book. What the URL buys you It is worth being precise about the advantages of the web as a delivery mechanism, because they shape design choices later. No installation. A visitor goes from curiosity to presence in the time it takes to load a page and press a button. For experiences that people encounter casually — a product page, a link from a teacher, a code on a museum wall — this is the difference between being visited and being ignored. No gatekeeper. A WebXR experience does not need approval from a platform's store. It can be published, revised or withdrawn on the author's schedule. For organisations that publish many small experiences, such as a retailer with a showroom per product line or a school with a simulation per lesson, the absence of a review process for each one is a decisive operational advantage. One codebase, many devices. The same URL serves a Quest, a Vision Pro, a Galaxy XR, a phone and a laptop. The experience will not be identical on each — it should not be — but it is one project rather than five. Instant updates. There is no installed version to fall out of date. When a content error is spotted in a training simulation, fixing it on the server fixes it for every learner. The rest of the web. A WebXR page is a web page. It can be linked to, embedded, indexed by search engines (at least in its surrounding text), measured with ordinary analytics, protected with ordinary login systems, and connected to ordinary back ends. A showroom can hand the visitor to the shop's existing basket. A simulation can report results to the school's existing learning platform. These advantages come with costs, and an honest account names them. A web page has less direct access to hardware than a native app and cannot use every platform-specific feature. JavaScript, although fast, runs with more overhead than compiled native code, and the browser's compositor adds a layer between your pixels and the displays. Assets must be downloaded each visit unless they are cached, which places real limits on how large a scene can be. And browsers differ, so testing is broader. None of these costs is prohibitive for showrooms and educational simulations — they are rarely the kind of graphically extreme, hours-long experience that pushes a headset to its limits — but they set the boundaries within which good work is done. The rendering layer beneath it all WebXR itself draws nothing. It provides poses, views and a surface; the drawing is done by a graphics API. For most of the immersive web's history that API has been WebGL, a JavaScript binding to the OpenGL ES family of graphics interfaces, whose second version, WebGL 2, is available in every browser that supports WebXR. WebGL is old in design: it is a state machine in which the program sets switches and then issues drawing commands, and every drawing command carries a cost on the processor side that limits how many separate objects can be drawn per frame. WebGPU is its successor, designed around the architecture of modern graphics hardware and modern native APIs such as Vulkan, Metal and Direct3D 12. It reduces the processor-side cost of issuing work, exposes general-purpose compute shaders, and gives programs more explicit control over memory. As of late 2025, every major browser engine supports WebGPU in at least some configurations, including Safari 26 across Apple's platforms. The WebXR integration with WebGPU is newer than the WebGL one, and its availability inside immersive sessions varies by browser; at the time of writing, WebGL 2 remains the safe default for immersive work, with WebGPU an option to evaluate where it is supported. Three.js, the library examined in Chapter 3, abstracts over both, which is one of the strongest arguments for building on it rather than on either API directly. Few developers will write raw WebGL or WebGPU for a WebXR project, and this book does not recommend it. But the layer matters, because its constraints surface in every decision about assets and performance. When Chapter 5 explains why a scene of two thousand separate objects runs badly where a scene of two hundred runs well, the reason lies here. Inline content and the space between It is easy to think of WebXR purely in terms of the immersive moment, but much of what visitors actually see happens outside it. Before a visitor presses "Enter VR", and after they leave, they are looking at an ordinary page containing a 3D canvas. On a headset, that page floats as a flat window in the browser's environment; on a phone or laptop, it is the whole experience. The specification's inline mode exists for this space. An inline session lets a page use WebXR's frame loop and, on devices that permit it, orientation tracking, without taking over the displays — the "magic window" in which a phone becomes a window onto a 3D scene that the visitor looks around by moving the device. In practice, most frameworks render the non-immersive view with their own camera and controls rather than an inline session, which has the advantage of working in browsers with no WebXR support at all. Either way, the design question is the same: what should someone who has not yet entered, or cannot enter, see? A blank canvas with a button is the worst answer. A live, explorable preview of the space — the product on its plinth, the laboratory bench ready for the lesson — is the best, because it both serves visitors without headsets and persuades those with headsets that entering is worthwhile. Where the immersive web has stumbled A clear view of the field includes its failures. The most instructive is Mozilla Hubs, a browser-based social VR platform that let anyone create a shared room and invite others by link. It was among the most visible demonstrations of what the immersive web could be — and Mozilla shut down its hosted service on 31 May 2024 as part of a wider restructuring. The code survives, now maintained by an independent Hubs Foundation, and community instances continue. But organisations that had built their teaching or events on the hosted service had to migrate or stop. The lesson is not that the immersive web is fragile; the standards and the browsers outlasted Hubs, and the experiences built directly on them kept working. The lesson is about dependencies. An experience built on open standards and open-source libraries, hosted on infrastructure its owner controls, is about as durable as anything on the web. An experience built on someone else's hosted platform is exactly as durable as that platform's business case. Chapter 9 returns to this in practical terms. For now it is enough to note that the web's longevity is a property of its standards, not automatically of everything built with them. The controlling constraint If there is one idea to carry from this chapter into the rest of the book, it is that WebXR's advantages are all on the side of access, and its constraints are all on the side of capacity. The web makes it extraordinarily easy for someone to arrive. It makes it comparatively hard to deliver a heavy, intricate, hardware-maxing experience once they do. Good WebXR projects lean into this asymmetry. They choose subjects where being instantly present matters more than being photorealistic. They budget ruthlessly, so the first visit is fast and the frame rate never falters. They treat the visitor who arrives without a headset as a real audience rather than an afterthought. And they build on foundations — the standard, open libraries, their own hosting — that will still be there when the next headset arrives. The next chapter goes one layer deeper, into what actually happens between a click on "Enter VR" and the first frame on a headset's displays. Chapter 2: Anatomy of a WebXR Session Most developers will build WebXR experiences through a framework, and frameworks are good at hiding the underlying API. That is their purpose. But a framework hides an API in the way a car's dashboard hides an engine: perfectly well until something goes wrong, at which point the driver who knows what a fuel pump does has a large advantage. When a scene appears at the wrong height, when controllers point in odd directions, when the frame rate collapses only inside the headset, when an experience works on one device and silently fails on another, the explanation is almost always somewhere in the lifecycle of a session. This chapter walks through that lifecycle from start to finish. Asking whether, then asking for Everything begins with navigator.xr, an object of type XRSystem that exists in browsers implementing WebXR. Its absence is the first and simplest signal: if navigator.xr is undefined, this browser offers no immersive capability at all, and the page should present its non-immersive version without further ceremony. If it exists, the page asks a more specific question with isSessionSupported, passing the mode it wants — usually immersive-vr. The answer arrives asynchronously, as a promise that resolves to true or false. A true answer means the browser believes it could start such a session: a compatible headset is present, or the browser is running on one. A false answer means it could not, at least not now. A desktop browser with no headset connected will typically say false for immersive-vr; an Android phone will say false for immersive-vr but may say true for immersive-ar. The page should use this answer to decide what to show. The convention is to display an "Enter VR" button only when the answer is true, and otherwise either hide it or replace it with an explanation — "Open this link on a VR headset to step inside" — that converts a dead end into a useful instruction. Both Three.js and A-Frame generate such buttons automatically, and both handle the unsupported case, but their defaults are generic, and a project that cares about its audience will usually customise the message. The actual request is requestSession, again passing the mode, plus an optional dictionary of features. This call must be made in response to a user gesture, which in practice means inside the click handler of the button. If it is called at any other time — on page load, after a timer, after an asynchronous fetch has returned — it will be rejected. This catches developers out more often than any other rule in the specification, usually when they insert an innocent-looking await between the click and the request, for example to load an asset first. The user activation that a click grants is transient: it lasts only a short window, and anything that pushes the request past that window loses it. The robust pattern is to load what you need before showing the button, or to request the session immediately on click and load inside the session. Features: required and optional The features dictionary is where a page states what it needs beyond the basics. It has two lists. requiredFeatures names capabilities without which the session should not start at all; if the browser cannot provide any of them, the request fails. optionalFeatures names capabilities the page would like and will use if available, but can live without. The features most commonly requested in VR are reference space types such as local-floor and bounded-floor, hand-tracking, and layers. In AR they include hit-test, anchors, dom-overlay and depth-sensing. Each may trigger a permission prompt from the browser, and the user may decline. The sound default is to require as little as possible and request the rest as optional. A showroom that would like hand tracking but works perfectly well with controllers should list hand tracking as optional; requiring it would lock out every user whose browser or device does not support it, and every user who declines the prompt. Requiring a feature should be reserved for cases where the experience is genuinely meaningless without it. After the session starts, the page can inspect the session's enabledFeatures (where the browser exposes it) or simply test whether the relevant objects are present, and adapt. Reference spaces: where is the floor? Once a session exists, the page needs a coordinate system in which to place its content and in which the browser will report the user's head and hands. WebXR calls these reference spaces, and choosing the right one is the source of many "why is everything at the wrong height" problems. The core specification defines five types. viewer is attached to the user's head and moves with it; it is useful for content that should stay fixed in the user's view, though such content is generally uncomfortable and should be used sparingly. local places the origin near the user's head position at the start of the session, with no knowledge of where the floor is; it suits seated experiences where the user does not move around. local-floor places the origin at floor level beneath the user's starting position, so that a value of zero on the vertical axis means the floor; this is the right choice for most standing experiences. bounded-floor adds knowledge of the safe play area the user has set up, exposed as a polygon, so that content can be arranged within it. unbounded is for experiences in which the user may walk freely over large distances, typically in AR. For showrooms and simulations, local-floor is the usual answer. It means a table modelled at seventy-five centimetres tall will appear at seventy-five centimetres, regardless of how tall the user is, and a user who sits down will see the table rise relative to their eyes, as it would in reality. Three.js uses local-floor by default, and A-Frame requests it as well. When a device cannot provide floor height, browsers generally emulate it using an estimated standing height, which is good enough for most purposes. A related concept is the offset. A page can derive a new reference space from an existing one, shifted and rotated by a transform. This is how teleportation works at the API level: rather than moving the entire virtual world, the page moves the user's reference space within it, and the browser reports all subsequent poses relative to the new origin. Frameworks wrap this in friendlier terms, but knowing that it is happening explains why teleportation in WebXR is cheap and why it does not disturb the physical relationship between the user's head and hands. The frame loop An ordinary web page that animates uses window.requestAnimationFrame, which calls a function before each repaint of the monitor, typically sixty times a second. An immersive session cannot use this, because the headset's displays run on their own clock — commonly 72, 90 or 120 times a second on current standalone headsets — and the browser must deliver frames in step with it. So the session provides its own requestAnimationFrame, and once a session starts, all rendering for the headset must happen inside callbacks scheduled through it. Each callback receives two arguments: a timestamp and an XRFrame. The frame is the page's window onto that instant. From it, the page asks for the viewer pose in its chosen reference space by calling getViewerPose. The pose contains the head's position and orientation, and, more importantly, a list of views. On a headset there are two views, one per eye. Each view carries its own transform — the position and orientation of that eye — and its own projection matrix, which describes the field of view and the perspective of that eye's display. The page's job is to render the scene once per view, using each view's transform and projection, into the region of the output surface that the browser assigns to that view. That output surface is the base layer. In the WebGL world it is an XRWebGLLayer created from the page's WebGL context and attached to the session through updateRenderState. The layer provides a framebuffer — the target the page draws into — and, for each view, a viewport describing which rectangle of that framebuffer belongs to which eye. The browser takes the finished framebuffer, hands it to the system compositor, and the compositor applies its own corrections, such as lens distortion and last-moment adjustments for head movement, before the image reaches the displays. Two consequences of this structure are worth absorbing early. The first is that the cost of rendering roughly doubles in VR compared with the same scene on a flat screen, because everything is drawn twice from slightly different viewpoints. Graphics systems have techniques to reduce the duplication, notably multiview rendering, in which both eyes are drawn in a single pass with the geometry submitted once; support for this varies, and frameworks enable it where they can. The second is that the pose is predicted. The browser does not report where the head is at the moment the callback runs; it reports where it predicts the head will be when the frame reaches the displays. This prediction is why well-performing VR feels solid. It is also why a page that takes too long to render breaks the illusion: the prediction was made for a deadline the page missed, and the compositor has to show something stale or reprojected instead. A minimal raw loop, stripped of all setup, looks like this: function onXRFrame(time, frame) { const session = frame.session; session.requestAnimationFrame(onXRFrame); const pose = frame.getViewerPose(refSpace); if (!pose) return; for (const view of pose.views) { const vp = glLayer.getViewport(view); gl.viewport(vp.x, vp.y, vp.width, vp.height); drawScene(view.projectionMatrix, view.transform.inverse.matrix); } } The callback first schedules the next one, so that an error in drawing does not silently stop the loop. It then asks for the pose; if tracking has been lost, the pose may be null, and the frame is skipped. For each view, it selects the correct viewport and draws the scene with that eye's matrices. Every framework's render loop, however elaborate, is doing this underneath. Input sources The session maintains a list of input sources, exposed as inputSources, and fires an inputsourceschange event when sources are added or removed. A controller being switched on, a hand coming into view of the tracking cameras, or a Vision Pro user beginning a pinch all add an input source. Pages should never assume the list is fixed. Each XRInputSource describes itself. Its handedness is left, right or none. Its targetRayMode says what kind of pointer it is: tracked-pointer for a controller or tracked hand whose ray follows the device; gaze for a ray that follows the head, used by simple viewers; screen for a tap on a phone's screen during an AR session; and transient-pointer for the gaze-and-pinch model described in Chapter 1. Its profiles property is a list of strings, from most specific to most generic, naming the kind of device — a particular manufacturer's controller, say, followed by a generic description such as a trigger-and-squeeze controller with a thumbstick. Libraries use these profile strings to load an accurate 3D model of the user's controller and to map its buttons. Each input source exposes up to two spaces. The targetRaySpace gives the origin and direction of the pointing ray — the line along which the user is aiming. The gripSpace, present for devices the user physically holds, gives the pose of the hand holding it, which is where a held object should be attached. Confusing these is a classic mistake: a sword attached to the target ray space will be angled oddly, because controllers' pointing rays are usually tilted relative to how they are gripped. Input arrives in two forms. Events — selectstart, select, selectend, and their squeeze equivalents — fire on the session for the primary action (typically the trigger or a pinch) and the secondary grab action (typically the side grip). These events are the most portable form of input, because every input source that can do anything at all supports select, and they also count as user activation for purposes such as starting audio. Polling is available for controllers through the gamepad property, which exposes buttons and axes in a standard layout called xr-standard. Thumbstick movement for locomotion, for instance, is read by polling the axes each frame. The design implication is to build interaction around select first, squeeze second, and gamepad axes third, so that the experience degrades gracefully from a full controller to a pinch to a single tap on a phone screen. When hand tracking is enabled, an input source representing a hand also exposes a hand object containing twenty-five joints, from the wrist through each knuckle to each fingertip, each with a pose and a radius. This is enough to render a convincing hand and to detect gestures such as a pinch or a poke. It is also a large amount of data, and using it well requires care, since hand tracking is noisier than controller tracking and fails when hands are out of the cameras' view or overlapping. Visibility, interruption and ending Sessions do not always run uninterrupted. On many headsets, pressing the system button brings up a menu over the experience. When that happens, the session's visibilityState changes from visible to visible-blurred (the page is still shown but not focused, and input is withheld) or to hidden (the page is not shown at all, and its frame callbacks may stop). A visibilitychange event announces each change. A page should pause anything time-sensitive — a timed quiz, a physics simulation, audio — when its visibility drops, and resume when it returns. Sessions end in several ways: the page can call end on the session; the user can exit through the system interface; the browser can end the session if the device disconnects. In every case an end event fires, and the page should restore its non-immersive state, restart its normal animation loop if it had one, and present the "Enter VR" button again. A surprising number of experiences break here, leaving a blank canvas after the user exits; testing the exit path is as important as testing the entry. Permissions and embedding Two final details matter for real deployments. The first is that immersive sessions are subject to a permissions policy named xr-spatial-tracking. A top-level page has it by default, but a page embedded in an iframe — a showroom embedded in a retailer's product page, or a simulation embedded in a learning platform — will be refused immersive sessions unless the embedding page explicitly grants it with an allow attribute on the frame. Many failed integrations come down to this one attribute. The second is that browsers may present their own consent prompts when a session starts or when sensitive features such as hand tracking or camera access are requested. Pages cannot suppress these, and should not try to anticipate their wording. What a page can do is prepare the user in its own interface: explaining, before the button is pressed, what the experience will ask for and why. Users who understand why a lesson wants to track their hands are far more likely to accept. Why this matters even with a framework Little of this chapter will appear in code that uses Three.js or A-Frame, both of which manage sessions, frame loops, reference spaces and input sources on the developer's behalf. But each concept resurfaces as a setting, a default, or a bug. When Three.js asks which reference space type to use, the choice is the one described here. When an A-Frame scene embedded in a learning platform refuses to enter VR, the missing permissions policy is the reason. When a hand-tracked interaction feels unreliable, the twenty-five joints and their noise are the cause. When frame rate collapses, the per-eye rendering and the predicted deadline explain the symptoms. A developer who understands the session can read a framework's documentation as a description of choices made on their behalf — and recognise when to override them. Chapter 3: Building with Three.js Three.js is the most widely used 3D library on the web, and for WebXR work it is the default foundation. Ricardo Cabello, known online as mrdoob, began it in 2010, and it has since grown into a large open-source project with a release roughly every two months and a vast ecosystem of examples, add-ons and derived tools. A-Frame is built on it. Meta's Immersive Web SDK is built on it. React Three Fiber, the popular bridge between React and 3D, is a renderer for it. Learning Three.js is therefore not a bet on one library among many; it is learning the substrate that most of the immersive web stands on. This chapter explains what Three.js gives a WebXR developer, how its WebXR integration is structured, and the handful of decisions that determine whether a Three.js project stays manageable as it grows. The scene graph Three.js organises a 3D world as a scene graph: a tree of objects, each with a position, rotation and scale relative to its parent. The root is a Scene. Beneath it hang Mesh objects (geometry plus a material), Group objects that exist only to hold children, lights, cameras, and anything else derived from the base class Object3D. Moving a parent moves everything beneath it. A showroom's sofa might be a group containing a frame mesh, three cushion meshes and four leg meshes; moving the group moves the sofa as a unit, while swapping a cushion's material changes its fabric. This hierarchy is the single most important structural idea in the library, and it matters doubly in VR. The user's head and hands are themselves objects in the graph. Three.js represents the headset's viewpoint as a camera whose transform it updates every frame from the WebXR pose, and it represents each controller as a group whose transform it updates from the input source's spaces. Attaching an object to a controller group — a tool, a laser pointer, a wrist menu — makes it follow that controller with no further code. Making a held object a child of the controller at the moment of a grab, and returning it to the scene at the moment of release, is the simplest correct way to implement picking things up. Three.js provides a method, attach, that reparents an object while preserving its world position, which is precisely what such grabbing needs. The other basic ingredients are geometry, the vertices and triangles that make a shape; materials, which decide how surfaces respond to light; textures, images mapped onto surfaces; and lights. For VR the material of choice in most projects is MeshStandardMaterial or its extended sibling MeshPhysicalMaterial, both of which implement physically based rendering, in which surfaces are described by real-world properties such as base colour, roughness and metalness rather than by ad hoc shading parameters. Physically based materials make objects respond plausibly to any lighting, and they are the language in which nearly all modern 3D assets are authored. Their cost, as Chapter 5 explains, is real, and on a standalone headset it has to be budgeted. Turning on XR The WebXR integration in Three.js lives on the renderer, in an object called renderer.xr, of class WebXRManager. Enabling it is a single property, and from that point the renderer knows how to take over a session: create the appropriate layer, read the viewer pose each frame, render the scene once per eye with the correct matrices, and hand the result back to the browser. What changes in the developer's code is the render loop. A non-XR Three.js page usually drives itself with the browser's requestAnimationFrame. That will not work inside an immersive session, for the reasons given in Chapter 2. Instead, Three.js provides setAnimationLoop on the renderer, which accepts a function and calls it every frame using whichever clock is appropriate: the window's when no session is active, the session's when one is. Using setAnimationLoop from the start, even before XR is added, is the simplest way to avoid a whole class of bugs. A complete minimal setup is short: import * as THREE from 'three'; import { VRButton } from 'three/addons/webxr/VRButton.js'; const renderer = new THREE.WebGLRenderer({ antialias: true }); renderer.xr.enabled = true; document.body.appendChild(renderer.domElement); document.body.appendChild(VRButton.createButton(renderer)); renderer.setAnimationLoop((time) => { renderer.render(scene, camera); }); VRButton is a small helper in the library's add-ons. It checks whether immersive-vr is supported, shows either an "Enter VR" button or a "VR not supported" message accordingly, and requests a session with local-floor and a set of commonly useful optional features when clicked. For production work most teams replace it with their own button that matches their design and offers clearer guidance to visitors without a headset, but it is an excellent starting point and a useful reference for how a session request should be shaped. An equivalent ARButton exists for AR sessions. Several settings on renderer.xr are worth knowing early. setReferenceSpaceType chooses the reference space before the session starts; local-floor is the default and usually correct. setFramebufferScaleFactor changes the resolution at which the scene is rendered relative to the device's recommended resolution; lowering it is one of the cheapest ways to recover performance, at a cost in sharpness. setFoveation sets the strength of fixed foveated rendering on devices that support it, reducing resolution towards the edges of the lenses where the optics blur the image anyway. Both are discussed in Chapter 5. During a session, renderer.xr.isPresenting tells the code whether the user is currently in VR, and the manager fires sessionstart and sessionend events. These are the right hooks for switching between the desktop and headset versions of an experience: hiding orbit controls, repositioning the scene, starting or stopping ambient audio. The camera in VR A frequent source of confusion is the camera. In a desktop Three.js scene, the developer creates a PerspectiveCamera, positions it, and renders through it. In VR, the developer still creates a camera and passes it to render, but its position and orientation are overwritten every frame by the headset pose. The camera the developer created becomes a stand-in for the user's head. This has two consequences. The first is that moving the camera directly does nothing useful in VR, because the next frame's pose replaces it. To move the user through the world, the developer moves something else — either the world itself, or, more cleanly, a parent object containing the camera and the controllers, often called a rig or dolly, or the reference space offset described in Chapter 2. Three.js's own teleportation example uses the reference space approach. Either approach works; mixing them in one project causes chaos. The second consequence is that the field of view, aspect ratio and near and far clipping planes of the developer's camera are mostly ignored in VR, since each eye's projection comes from the device. The near plane matters, though: if it is set too far away, objects held close to the face will be clipped. A near plane of a few centimetres is appropriate. Controllers and hands Three.js exposes WebXR input through three methods on renderer.xr. getController(index) returns a group that follows the target ray space of the input source at that index — the pointing ray. getControllerGrip(index) returns a group that follows the grip space — the hand holding the device. getHand(index) returns a group representing a tracked hand, with child objects for each of the twenty-five joints. The groups exist before any session starts and simply remain static until an input source occupies their index. Events are dispatched on these groups: selectstart, selectend, squeezestart, squeezeend, plus connected and disconnected, which fire when an input source arrives or leaves and carry the underlying XRInputSource as data. The connected event is where an application inspects handedness, targetRayMode and profiles to decide how to treat the source — showing a laser for a tracked controller, say, but not for a transient gaze-and-pinch pointer, which should show only a cursor where the user is aiming. For visual representations, the add-ons provide XRControllerModelFactory, which uses the input source's profile strings to fetch an accurate 3D model of the controller in use from the WebXR Input Profiles registry and animates its buttons and thumbsticks as the user presses them. XRHandModelFactory does the same for tracked hands, offering simple spheres, boxes, or a skinned mesh hand. Showing the correct controller model matters more than it sounds: people look at their hands constantly in VR, and seeing an unfamiliar controller in place of the one they are holding is a small but persistent break in presence. Pointing at things is implemented with raycasting. Three.js's Raycaster takes an origin and direction — read from the controller group's world transform — and returns the objects the ray intersects, sorted by distance. The same mechanism serves for mouse picking on desktop, using the camera and pointer position instead, so a single selection system can serve both. It is important to raycast only against objects that can actually be selected, maintained in a short list, rather than against the whole scene; casting against every mesh every frame is a common and avoidable source of lost performance. Loading real content Hand-built geometry is fine for prototypes. Real projects use models made in tools such as Blender, Maya or a product manufacturer's CAD pipeline, and on the web those models travel as glTF. glTF, maintained by the Khronos Group and published as an international standard (ISO/IEC 12113) in 2022, is designed as a transmission format: compact, quick to parse, and close to what a graphics API actually consumes. It describes meshes, physically based materials, textures, scene hierarchy, animations and cameras, and its binary form, GLB, packs everything into one file. Three.js loads glTF through GLTFLoader, an add-on that returns the scene hierarchy ready to add to the world. Two compression extensions are almost always worth using. Draco or Meshopt compression shrinks geometry, sometimes dramatically, and Three.js provides DRACOLoader and a Meshopt decoder to unpack them. KTX2 textures with Basis Universal compression shrink textures and, more importantly, stay compressed in GPU memory; Three.js provides KTX2Loader for them. Chapter 5 explains why the second of these matters so much on a headset. Loading is asynchronous and can take seconds on a mobile connection, which raises a design question unique to the immersive web: what does the user see while it happens? The safe answer is to load the essential content before showing the "Enter VR" button, with a progress indication in the page, and to load secondary content — further rooms, alternative product finishes — progressively once the user is inside. Three.js's LoadingManager reports overall progress across many loaders and is the natural hook for this. Choosing a renderer: WebGL and WebGPU For most of its history Three.js had one serious renderer, WebGLRenderer. It now has two. WebGPURenderer, imported from the three/webgpu entry point, has been considered production-ready since release r171 in late 2024. It uses WebGPU where the browser supports it and falls back automatically to WebGL 2 where it does not, so the same code can run in both. It brings a new way of writing custom materials, TSL, the Three Shading Language, in which shaders are composed from JavaScript functions rather than written as strings of shader source, and which compiles to whichever backend is in use. For WebXR the choice is less settled than for flat-screen work. The WebXR integration in WebGLRenderer is mature and battle-tested on every headset. WebXR support in WebGPURenderer arrived more recently and, at the time of writing, depends on browsers exposing a WebGPU path for immersive sessions, which not all do; where they do not, the renderer's WebGL 2 fallback is used. A practical approach for a project starting in 2026 is to build on WebGLRenderer for the immersive path unless there is a specific reason to need WebGPU — heavy compute work, for instance, or a large number of objects that would benefit from WebGPU's lower per-draw cost — and to keep custom shader code minimal so that a later move is cheap. Teams that already use TSL for their flat-screen work will find the move easier than teams with large hand-written GLSL shaders. Keeping a Three.js project manageable Three.js is a library, not a framework. It provides objects and leaves the architecture to the developer. Small projects can live comfortably in one file; projects that grow — a showroom with a dozen products, a simulation with several lessons — become unmanageable without some structure imposed from outside. Three disciplines make the biggest difference. The first is to separate state from presentation. The product configuration a customer has chosen, or the step a student has reached in a procedure, should live in plain data structures that know nothing about meshes. The 3D scene should be updated from that state, not the other way round. This makes it possible to show the same state in a 2D interface on a phone, save it, send it to a server, or reset it, without touching rendering code. The second is to organise behaviour into small, reusable units attached to objects, rather than one enormous animation loop full of conditionals. This is, in effect, the entity-component pattern that A-Frame formalises and that Meta's Immersive Web SDK builds into an entity-component-system architecture. Teams using plain Three.js can adopt the pattern informally — an object can carry a list of behaviours, each with its own update function — and gain much of the benefit. The third is to dispose of what is no longer needed. Three.js does not free GPU memory automatically when an object is removed from the scene; geometries, materials and textures must be disposed explicitly. On a desktop this is a minor leak. On a standalone headset with a few gigabytes of memory shared between the system, the browser and the page, an experience that loads product after product without disposing of the old ones will eventually crash the tab. Common first-week problems Developers new to WebXR in Three.js tend to meet the same handful of problems, and recognising them saves hours. The scene is at the wrong height. Usually the scene was designed with the camera at a height of, say, 1.6 metres and the floor at zero, and then the camera position was also set to 1.6 in code. In VR, with a local-floor reference space, the headset pose already includes the user's real height, so the extra offset puts their eyes well above where they should be — or, if the floor was placed at minus 1.6 to compensate on desktop, sinks the world below the real floor. The fix is to model the world with the floor at zero and let the device supply the head height in VR, applying a desktop camera height only when not presenting. Everything is too big or too small. Models exported from design tools in centimetres arrive a hundred times too large; models in inches, roughly forty times. Since VR makes scale immediately obvious, these errors are glaring. Checking scale against a known real dimension on import, and correcting it at the asset stage rather than with a scale factor in code, prevents both confusion and inconsistent physics or raycasting later. The controllers point the wrong way. Typically, an object meant to be held was attached to the target ray group rather than the grip group, or a pointing ray was attached to the grip. Chapter 2's distinction between the two spaces explains the symptom. It runs on desktop but not in the headset. Frequently the cause is a page served over plain HTTP from a development machine's network address, which is not a secure context, so navigator.xr is unavailable. Occasionally it is a feature listed as required that the headset's browser does not support. The remote debugging tools described in Chapter 9 show the error directly. It runs, but badly. Almost always this is one of the costs described in Chapter 5 — too many draw calls, uncompressed textures, real-time shadows — and the frame statistics will usually point to which. When Three.js is the right choice Three.js suits projects where the developer wants direct control over rendering and interaction, where the team is comfortable in JavaScript, and where the experience has particular needs that a higher-level tool might obstruct: a custom material for a fabric sample, a particular way of loading a very large model, an unusual interaction technique, integration into an existing application built with React or another framework. Its vast ecosystem of examples means that almost any technique has been demonstrated somewhere, and its official examples include clean, small demonstrations of controllers, hand input, teleportation, layers and more. Its cost is that everything above the rendering layer is the developer's responsibility. Locomotion, comfort settings, menus in 3D, grab interactions, desktop fallbacks — all must be built or assembled. For many projects that is exactly the right trade. For others, particularly where the team includes people who are not primarily programmers, a more declarative tool on top of Three.js gets further, faster. That tool is the subject of the next chapter. Hashtags: #WebXRDevelopment #VirtualReality #ImmersiveWeb #WebXRDeviceAPI #BrowserBasedVR #ImmersiveVR #ThreeJS #AFrame #WebGL #WebGPU #XRSession #ReferenceSpaces #XRInputSources #HandTracking #ControllerTracking #SceneGraph #GLTF #XRRendering #FrameRateOptimization #VRPerformance #CrossDeviceExperiences #VirtualShowrooms #EducationalSimulations #ProgressiveImmersion #FutureOfWebXR

Download the Book (PDF): Introduction On the morning of 7 May 2021, operators at Colonial Pipeline shut down the largest refined-fuel pipeline in the United States. Ransomware had reached the company's business systems, and nobody could say with confidence how far it had spread or whether the operational network that moved gasoline, diesel and jet fuel up the East Coast was safe. Panic buying followed. Filling stations in several states ran dry. A month later the company's chief executive, Joseph Blount, told a Senate committee how the intruders had got in. They had used the password of a legacy virtual private network account. The account was no longer meant to be in use. It was not protected by multi-factor authentication. One valid username and one valid password were enough to put an attacker on the corporate network. It is tempting to read that story as a lesson about passwords, and it is one. But the more important lesson is about what the password unlocked. A VPN account does not grant access to an application. It grants access to a network. Once the tunnel is up, the remote machine is, for most practical purposes, sitting inside the building, and everything reachable from inside the building is reachable from it. The password was the weak point; the architecture was what turned a weak point into a national emergency. This booklet is about replacing that architecture. Its subject is Zero Trust Network Access, usually shortened to ZTNA: the family of designs in which a user is connected not to a network but to specific applications, one request at a time, after an explicit decision that weighs who the user is, what device they are on, what they are asking for and whether anything about the situation looks wrong. The decision is made again and again over the life of a session rather than once at the front door. The applications themselves are hidden from the internet and from each other; they can be reached only through a broker that enforces those decisions. When it works, a stolen password opens nothing on its own, a compromised laptop reaches only what its owner was entitled to, and the corporate network stops being a place where an intruder can wander. Why the VPN has become the problem For three decades the VPN was the sensible answer to a sensible question: how do people outside the office reach systems inside it? The answer was to extend the inside outward through an encrypted tunnel. That answer made sense when most applications lived in a company data centre, most employees worked in an office, and the occasional remote worker used a company-issued laptop that rarely left the corporate fleet. None of those conditions hold any more. Applications live in software-as-a-service platforms and public clouds as often as in the data centre. Remote and hybrid work is normal rather than exceptional. Contractors, partners and outsourced support teams need narrow access to specific systems, not a seat on the internal network. Meanwhile the VPN concentrator itself has become one of the most attacked pieces of equipment in the enterprise. It must be reachable from the whole internet, it runs complex code that parses untrusted input before the user has authenticated, and it sits at precisely the point where a successful exploit yields the most. Since 2019, flaws in remote-access appliances from almost every major vendor have been exploited at scale, sometimes by criminal groups and sometimes by state-sponsored ones. Twice in the space of two years, the United States Cybersecurity and Infrastructure Security Agency issued emergency directives ordering federal agencies to act on compromised remote-access and firewall appliances, once for Ivanti Connect Secure in January 2024 and again for Cisco's Adaptive Security Appliances in September 2025. The pattern in these incidents is consistent. Either an attacker obtained a valid credential, or an attacker exploited the gateway directly; in both cases the reward was broad network access, and the damage depended on how flat that network turned out to be. Better patching and stronger passwords help, but they leave the reward unchanged. Zero trust changes the reward. What zero trust is, and what it is not "Zero trust" is now a marketing phrase as well as an engineering idea, and the marketing has done the idea few favours. It is not a product. It does not mean that nobody is trusted; it means that trust is never assumed from network location and is instead granted explicitly, narrowly and temporarily, on the basis of evidence. The clearest statement of the idea remains the United States National Institute of Standards and Technology's Special Publication 800-207, Zero Trust Architecture, published in August 2020. Its practical antecedent is Google's BeyondCorp programme, begun after the company was targeted in the intrusion campaign that became known as Operation Aurora and described publicly from 2014 onward. Its policy momentum in the public sector came from Executive Order 14028 in May 2021 and the Office of Management and Budget's federal zero trust strategy, memorandum M-22-09, in January 2022. Its most widely used yardstick is CISA's Zero Trust Maturity Model, whose second version appeared in April 2023. ZTNA is the part of zero trust that most directly replaces the VPN. It is not the whole of zero trust, which also reaches into data classification, workload-to-workload communication, network segmentation inside the data centre, and security operations. But it is usually where an organisation starts, because it touches every remote user, because the VPN is a visible and costly risk, and because the move forces the organisation to confront the questions on which everything else depends: who are our users, what are our devices, what are our applications, and who should reach what. The argument of this booklet The claim running through every chapter is simple to state and harder to carry out. The corporate VPN fails because it uses network location as a stand-in for trust; ZTNA succeeds only when it replaces that stand-in with real evidence about identity, device and context, enforced at each application. Organisations that treat ZTNA as a product to swap in for the VPN usually rebuild the old flat network in a new console. Organisations that treat it as an identity and inventory programme, with the proxy as the last step rather than the first, get the security benefit. The chapters follow that logic. The first explains precisely how the perimeter model and the VPN work, and why their failures are structural rather than incidental. The second traces where zero trust came from and what the major frameworks actually say, as opposed to what vendors say they say. The next two chapters cover the two sources of evidence on which every access decision rests: the identity of the person, verified continuously rather than once, and the posture of the device they are using. The fifth chapter describes the identity-aware proxy and the other mechanics that put a ZTNA decision into effect. The sixth deals with policy, the part most often neglected, because a perfect enforcement mechanism applying a careless rule produces a careless result. The seventh is a practical account of migration, including the long tail of applications that do not fit neatly into the new model. The eighth covers operating the result: what to measure, what to watch, and what ZTNA does not solve. The perspective throughout is that of the defender and the architect: the person who must design something that works on Monday morning for thousands of users, survives an audit, and makes an attacker's job measurably harder. Where a vendor's terminology helps, it is used; where it obscures, it is translated. Where the evidence is thin, the booklet says so. A note on scope. The examples assume a mid-sized or large organisation with a mixture of software-as-a-service, cloud-hosted and data-centre applications, a workforce that is at least partly remote, and some third parties who need access. Smaller organisations face the same logic with fewer moving parts. Operational technology and industrial control environments, where the stakes and constraints differ sharply, are discussed where they intersect with remote access but are not treated in full. The VPN served its purpose well for a long time. The point is not that the people who deployed it were wrong. It is that the world it was designed for has gone, and attackers noticed before many defenders did. Chapter 1: The Castle and the Tunnel Every security architecture rests on an assumption about where danger comes from. For most of the history of enterprise computing, the assumption was geographic. Danger lived outside. Inside the corporate network, behind the firewall, were employees, company computers and company servers; outside was the internet, full of strangers. The job of security was to draw a hard line between the two and police the crossing points. The metaphor that stuck was the castle: thick walls, a moat, a drawbridge, and inside, a courtyard where people moved freely. The castle model was not foolish. In the 1990s and early 2000s it matched how organisations actually worked. Servers sat in a room the company owned. Desktops were wired to switches in the same building. The number of connections to the outside world was small and could be counted. A firewall at each of those connections could enforce a short, comprehensible policy: let mail in to the mail server, let web traffic out through the proxy, block nearly everything else. Inside, the network was trusted because the people on it had passed through physical security, had been hired by the company, and were using machines the company had built and controlled. How the VPN extended the castle Remote access posed an obvious problem for this model. A travelling salesperson, a system administrator on call at night, or an executive working from home needed to reach systems that lived inside the walls. Early solutions were dial-up modem banks, which were slow and expensive. The virtual private network solved the problem elegantly. It built an encrypted tunnel across the public internet from the remote computer to a gateway on the edge of the corporate network, usually called a VPN concentrator. Traffic entering the tunnel was wrapped, encrypted, carried across the internet and unwrapped at the gateway, which then placed it on the internal network as if it had originated there. Two technical families dominated. IPsec VPNs operate at the network layer and were standardised by the Internet Engineering Task Force in the late 1990s; they were the first choice for connecting branch offices to headquarters and remained common for user access. SSL VPNs, which later moved to TLS, run over the same protocol that secures web browsing and became popular for remote users because they passed easily through hotel and home firewalls and could be launched from a browser or a lightweight client. In either case, once the tunnel was established the remote device usually received an internal IP address from a pool the concentrator managed, and the corporate routing tables were updated so that traffic to internal destinations flowed through the tunnel. The key consequence is easy to miss because it is the whole point of the design. A VPN connection does not connect a person to an application. It connects a device to a network. Authorisation, where it existed, was typically expressed as network rules: users in a certain group were placed in a certain address pool, and firewall rules on the inside allowed that pool to reach certain subnets. In practice those rules were coarse, because writing and maintaining fine-grained rules for thousands of users and hundreds of applications was laborious, and because the network team that owned the firewall rarely knew in detail which people needed which applications. The common result was that any authenticated VPN user could reach a large part of the internal network, often far more than their job required. Many deployments added "split tunnelling" to manage bandwidth. With split tunnelling, only traffic destined for corporate addresses goes through the tunnel, while general internet traffic goes straight out of the user's home connection. Without it, every packet, including video calls and software updates, hairpins through the corporate data centre. Split tunnelling was a performance compromise that also exposed a security truth: the VPN had always been a statement about where traffic went, not about whether the person or device behind it deserved to be there. Four structural weaknesses The problems with the VPN are often described as a list of bugs. They are better understood as consequences of the castle assumption, which is why patching them one by one has never closed the gap. There are four. First, authentication happens once, at the gate, and then trust is implicit. A typical VPN session checks credentials when the tunnel is established and then trusts the tunnel for hours or days. If the credential was stolen, the attacker enjoys the same standing as the legitimate user for the life of the session. If the laptop is infected with malware after the tunnel is up, the malware inherits the tunnel. If the user changes roles or is terminated, the existing session may survive until it times out. Nothing in the architecture asks, at the moment someone opens a sensitive database, whether this is still the right person on a healthy machine. Second, access is to the network, not to the resource. Because the unit of access is an address range, every authenticated user becomes a potential starting point for lateral movement. Attackers who reach the inside do not need to know in advance where valuable data lives; they can scan, enumerate directory services, find file shares and administrative interfaces, and move from one foothold to the next. The 2013 breach of the retailer Target is the textbook case: attackers entered using credentials belonging to a refrigeration and HVAC contractor that had network access for billing and project management, and from that foothold reached the point-of-sale systems that processed customer payments. The contractor never needed a path to payment systems. The flat network gave one anyway. Third, the gateway is exposed to the whole internet and is complex. For the VPN to serve remote users, the concentrator must accept connections from anywhere. It must parse packets and handshakes from unauthenticated clients, which means its pre-authentication code is the attack surface. These devices typically run proprietary operating systems on appliances that customers cannot inspect, cannot run endpoint detection software on, and often cannot patch quickly without scheduling downtime for the entire remote workforce. Their logs are frequently thin. When they are compromised, defenders may struggle even to tell. Fourth, the model has no good answer for the modern application estate. When an application moves to a software-as-a-service provider, the VPN is either irrelevant or actively harmful. Some organisations force all traffic, including traffic to cloud services, back through the corporate network so that it can be inspected and so that the cloud application can restrict logins to the company's IP addresses. This makes the VPN gateway a performance bottleneck and a single point of failure for the whole business, and it confuses network origin with legitimacy, since an attacker on a compromised VPN session also arrives from a corporate address. Contractors and partners pose a parallel problem: giving them VPN accounts places third-party machines, which the organisation does not manage, inside the castle walls. What the incidents show The years since 2019 have produced a dense record of attacks on remote-access infrastructure. Taken together, they show the four weaknesses operating in the wild. In 2019, a critical arbitrary-file-read flaw in Pulse Secure's Pulse Connect Secure VPN, tracked as CVE-2019-11510, allowed unauthenticated attackers to retrieve files from the appliance, including files that could contain cached plaintext credentials. A patch was released in April 2019, but many organisations were slow to apply it, and some that patched did not reset the credentials that had already been exposed. Ransomware operators exploited the flaw widely; the foreign-exchange company Travelex, hit by ransomware on the last day of 2019, had been widely reported to be running unpatched Pulse Secure servers in the months before the attack. In December 2019 a separate flaw in Citrix's Application Delivery Controller and Gateway products, CVE-2019-19781, was disclosed and exploited within weeks. In September 2021, a threat actor published a list of login credentials for roughly 87,000 Fortinet FortiGate SSL VPN devices, around half a million username and password pairs in total. Fortinet stated that the credentials had been harvested from devices vulnerable to CVE-2018-13379, a path-traversal flaw patched in 2019. As with Pulse Secure, patching closed the hole but did not invalidate the credentials already stolen, which continued to work wherever passwords had not been reset. Here the single-gate model is laid bare: a set of passwords, once taken, was a ticket inside for anyone who held it. In October 2023 came Citrix Bleed, CVE-2023-4966, a memory-disclosure flaw in NetScaler ADC and Gateway that leaked session tokens from the appliance's memory. An attacker who obtained a valid session token could take over an authenticated session without needing a password or a multi-factor prompt, because the authentication had already happened. Ransomware affiliates using the LockBit 3.0 toolkit exploited it against a range of victims, and a joint advisory from CISA, the FBI and partner agencies described its use against Boeing. The lesson is subtle and important. Multi-factor authentication at the gate is necessary, but if the architecture then trusts the session for its whole life, stealing the session is as good as stealing the factors. In January 2024, Ivanti disclosed two vulnerabilities in its Connect Secure and Policy Secure gateways, the descendants of the Pulse Secure product line: an authentication bypass, CVE-2023-46805, and a command-injection flaw, CVE-2024-21887. Chained together, they gave unauthenticated attackers the ability to run commands on the appliance. The flaws had been exploited as zero-days before disclosure, and exploitation spread rapidly once they became public. CISA issued Emergency Directive 24-01 on 19 January 2024, and on 1 February it issued supplemental direction instructing federal agencies to disconnect all affected Ivanti products from their networks within roughly a day and to treat them as potentially compromised. Investigators also found that attackers had taken steps to evade the vendor's own integrity-checking tool. A year later, in January 2025, Ivanti disclosed another exploited flaw in Connect Secure, CVE-2025-0282, a stack-based buffer overflow that allowed unauthenticated remote code execution. In September 2025 CISA issued Emergency Directive 25-03, directing federal agencies to identify and mitigate potential compromise of Cisco Adaptive Security Appliance and Firepower devices, after a campaign linked to the actor behind an earlier operation known as ArcaneDoor exploited newly disclosed vulnerabilities and, on some older hardware, modified the devices' read-only memory to persist through reboots and upgrades. These are not obscure products from careless vendors. They come from the largest companies in the networking and security industry. The point is not that one vendor is worse than another. It is that any device which must accept unauthenticated connections from the whole internet, runs complex parsing code, and yields broad network access on success will be an attractive and recurring target. Attackers invest where the payoff is largest, and for a decade the VPN concentrator has offered one of the largest payoffs available. What an intruder does with a tunnel It helps to follow what typically happens after an attacker obtains a working VPN session, whether through a stolen password, a hijacked token or an exploited gateway. The steps are well documented in incident reports and government advisories, and they are depressingly consistent. The first hours are spent on orientation. The attacker's machine has an internal address and can resolve internal hostnames, so it can query the organisation's directory service, usually Active Directory, which by default answers questions from any authenticated account about users, groups, computers and trust relationships. Within minutes the attacker knows the names of the domain administrators, the servers that hold file shares, the database hosts, and often the naming convention that reveals which machines are backups, which are finance and which are development. Scanning tools sweep internal subnets for open remote desktop, SSH, database and web-management ports. None of this is unusual traffic on an internal network, and in many organisations none of it is logged in a way anyone reviews. The next stage is privilege escalation. Common techniques exploit the way the directory and its authentication protocols are configured rather than any software flaw: requesting service tickets that can be cracked offline to reveal service-account passwords, finding credentials left in scripts on file shares, or reaching a workstation where an administrator has recently logged in and harvesting the cached credentials from memory. Each of these depends on reachability. The attacker can try them because the network lets the VPN session talk to nearly everything. The final stage depends on the attacker's purpose. Espionage groups locate and quietly copy data, often for months. Ransomware operators copy data for extortion, disable or delete backups, and then push encryption software to as many machines as possible at once, typically using the same administrative tools the IT department uses. In the Colonial Pipeline case, the business network was encrypted and the company shut down the pipeline's operations as a precaution because it could not be sure how far the intrusion reached. At every one of these stages, the VPN's contribution was the same: it delivered the attacker to a vantage point from which the whole internal network was visible and most of it was reachable. A design in which the stolen session could reach only the specific application its owner used, and in which the directory, the file servers and the management interfaces were simply not addressable from it, would have stopped the sequence at the first step. That is the property zero trust aims to provide. Why hardening the VPN is not enough A reasonable objection is that each of these incidents had a conventional remedy. Patch faster. Require multi-factor authentication. Rotate credentials after a breach. Segment the internal network with firewalls so that VPN users can reach only what they need. Shorten session lifetimes. All of this is sound advice, and an organisation that cannot do it will struggle with zero trust as well. But notice what the remedies amount to when pursued to their logical end. Requiring strong authentication for every user, re-checking it during the session, restricting each user to the specific applications they need, checking the health of the device before and during access, logging every access decision, and removing the exposed gateway from the internet: that is not a hardened VPN. It is a zero trust architecture assembled by hand from pieces never designed for the purpose. The VPN's network-level tunnel becomes an obstacle rather than an aid, because it keeps granting reachability that the other controls are then working to take away. There is also a practical asymmetry. Segmentation behind a VPN must be maintained in the network layer, typically by a network team, using address ranges that change as applications move. Access decisions in a zero trust architecture are expressed in terms of identities and applications, which are what the business actually reasons about. A rule that says "members of the finance team, on managed devices, may reach the general ledger application" can be read and approved by the head of finance. A rule that says "the address pool 10.20.32.0/20 may reach 10.40.8.15 on ports 443 and 8443" cannot. The shift in one sentence The rest of this booklet elaborates one change of assumption. In the castle model, the question at the gate is "are you allowed onto our network?", and the answer, once given, stands. In a zero trust model, the network is assumed to be hostile everywhere, inside and out, and the question is asked at every application, for every request: "given who you are, what you are using, and what you are trying to do right now, should this specific action be allowed?" The answer is allowed to change. That question cannot be answered with a tunnel. It needs reliable knowledge of identity, reliable knowledge of device state, a place to make decisions, and a place to enforce them close to the resource. The ideas behind that design did not appear suddenly in vendor brochures. They were worked out over more than fifteen years, by a loose community of security architects, by one very large company that had been badly burned, and finally by government standards bodies trying to make the ideas usable by everyone else. That history is the subject of the next chapter. Chapter 2: Where Zero Trust Came From Ideas in security tend to arrive twice: once as a warning that few people act on, and again, years later, as a requirement nobody can ignore. Zero trust followed that path. Its core insight, that a network's interior should not be trusted merely for being the interior, was stated clearly in the mid-2000s. It took a large and very public intrusion, a decade of engineering at one company, and a run of damaging breaches across government and industry before it became mainstream practice. Knowing the history is not an academic exercise. Each stage contributed something specific to how ZTNA works today, and the frameworks that emerged are the documents an architect will be measured against. The warning: de-perimeterisation and "no more chewy centres" In 2004 a group of chief information security officers from large organisations, mostly European, formed the Jericho Forum under the umbrella of The Open Group. Their observation was that the network perimeter was eroding whether security teams liked it or not. Business partners needed direct connections; mobile devices were proliferating; applications increasingly reached across organisational boundaries. The forum called the trend "de-perimeterisation" and argued that security should move closer to data and applications instead of depending on a boundary that was already full of holes. Its "commandments", published in 2007, included the principle that access to data should be controlled by security attributes of the data itself, and that all devices must be capable of maintaining their security policy on an untrusted network. The forum disbanded in 2013, its ideas absorbed into later work, but it had named the problem. In 2010 John Kindervag, then an analyst at Forrester Research, gave the idea its lasting name. His report, No More Chewy Centers: Introducing the Zero Trust Model of Information Security, attacked the common practice of hard perimeter defences around soft, trusting interiors. Kindervag's original model was network-centric: he proposed segmenting networks into small zones around valuable assets, inspecting and logging all traffic, and enforcing least-privilege access between zones, so that no packet was trusted because of where it came from. The emphasis on the network reflected the technology of the time, and later formulations moved the centre of gravity toward identity. But the slogan "never trust, always verify" stuck, and so did the insistence that trust be treated as a vulnerability to be minimised rather than a convenience to be granted. Neither the Jericho Forum nor the original Forrester model produced a widely deployed blueprint for remote access. That came from an organisation that had been forced to rethink its security from the ground up. The proof: Operation Aurora and BeyondCorp In January 2010 Google disclosed that it had been the target of a sophisticated attack originating in China, which had resulted in the theft of intellectual property; the company said that at least twenty other large companies had been targeted in the same campaign. The intrusion, which became known as Operation Aurora, began with targeted attacks on employees and moved through the corporate network from there. For an organisation that already thought of itself as technically sophisticated, the lesson was humbling. A perimeter that could be bypassed by compromising a single employee's workstation provided less protection than its cost suggested. Google's response was an internal programme called BeyondCorp. Its premise, set out in the first of a series of papers by Rory Ward and Betsy Beyer in the USENIX magazine ;login: in December 2014, was that access should depend solely on what was known about the user and the device, not on the network from which the request originated. Being on the corporate network would confer no privilege at all. Employees in a Google office would reach internal applications in exactly the same way as employees in a coffee shop: over the internet, through an access proxy, after a decision based on their identity and the state of their machine. Several components made this work, and they map closely onto what ZTNA products provide today. • A device inventory. Google built a database of every device it managed, with each device identified by a certificate. Access decisions could only be as good as knowledge about the machine making the request, so a trustworthy, continuously updated inventory was a prerequisite rather than an afterthought. • A user and group database. Identity came from the company's directory and was tied to HR processes, so that joining, moving between roles and leaving were reflected in access automatically. • An access proxy. Every internal application was placed behind an internet-facing proxy that terminated the connection, authenticated the user and device, and forwarded the request only if policy allowed. Applications themselves were no longer reachable directly. • A trust inference engine and access control engine. Rather than a simple allow or deny on group membership, BeyondCorp assigned devices and users trust tiers derived from many signals, such as patch level and configuration, and required a minimum tier for each application. • An unprivileged network. Even in offices, user devices were placed on a network segment that was treated like the internet, with no special access to internal resources. Later papers in the series, published between 2016 and 2018, are unusually frank about the hard parts: how to migrate thousands of applications without breaking them, how to handle services that did not speak HTTP, how to keep the user experience acceptable, and how to keep a fleet of heterogeneous devices healthy enough to pass policy. The migration took years. It was, in the authors' own description, a gradual process of moving users and applications off the privileged network, guided by careful measurement of what traffic still depended on it. BeyondCorp mattered for two reasons. It showed that a large organisation could run without a privileged internal network at all. And it described the architecture concretely enough that others could copy it, which, over the following years, the security industry did. Google itself later turned parts of the system into commercial offerings, and the identity-aware proxy pattern became the template for the ZTNA market. Standards, mandates and yardsticks The standard: NIST SP 800-207 By the late 2010s "zero trust" had become a crowded marketing category, and buyers needed a vendor-neutral definition. The United States National Institute of Standards and Technology supplied one in August 2020 with Special Publication 800-207, Zero Trust Architecture, written by Scott Rose, Oliver Borchert, Stu Mitchell and Sean Connelly. It is short, readable and remains the most cited reference in the field. SP 800-207 defines zero trust as a set of concepts aimed at minimising uncertainty in enforcing accurate, least-privilege, per-request access decisions in information systems, in the face of a network viewed as compromised. It then sets out seven tenets, which are worth paraphrasing because nearly every design choice in later chapters follows from them. All data sources and computing services are considered resources, including personal devices that access enterprise resources and software-as-a-service applications. All communication is secured regardless of network location; being on the enterprise network does not imply trust. Access to individual enterprise resources is granted on a per-session basis, with only the least privileges needed for the task, and access to one resource does not automatically grant access to another. Access is determined by dynamic policy, including the observable state of the client identity, the application or service, and the requesting asset, and may include other behavioural and environmental attributes. The enterprise monitors and measures the integrity and security posture of all owned and associated assets; no asset is inherently trusted. All resource authentication and authorisation are dynamic and strictly enforced before access is allowed, in a constant cycle of obtaining access, scanning and assessing threats, adapting, and continually re-evaluating trust. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture. The document's most useful contribution for architects is its logical model. It separates the system into a policy engine, which makes the access decision; a policy administrator, which acts on that decision by establishing or tearing down the communication path; and a policy enforcement point, which sits in the data path and allows, monitors or terminates connections between a subject and a resource. The engine and administrator together form the policy decision point. The decision is fed by external sources: identity management, device management and diagnostics, threat intelligence, activity logs, data access policies, and the public-key infrastructure. The separation of decision from enforcement is what makes it possible to change policy centrally while enforcing it at many points close to the resources. SP 800-207 also describes variations in how the model can be deployed: approaches centred on enhanced identity governance, on micro-segmentation, or on network infrastructure and software-defined perimeters; and deployment models in which an agent on the device talks to a gateway in front of the resource, a gateway protects an enclave of resources, or a portal brokers access for devices that cannot run an agent. Most ZTNA products are combinations of these patterns. The publication is candid that none is universally best and that most enterprises will run a hybrid of zero trust and perimeter-based architecture for a long time. In June 2025 NIST's National Cybersecurity Center of Excellence followed with SP 1800-35, Implementing a Zero Trust Architecture, a practice guide that documents nineteen example implementations built with commercial products from a large group of collaborating vendors. Where SP 800-207 explains what a zero trust architecture is, SP 1800-35 shows what assembling one with real products looks like, including the integration gaps. The mandate: Executive Order 14028 and M-22-09 Standards describe; mandates move budgets. In May 2021, days after the Colonial Pipeline attack and months after the disclosure of the SolarWinds supply-chain compromise, the White House issued Executive Order 14028, Improving the Nation's Cybersecurity. Among many provisions, it directed federal agencies to develop plans to adopt zero trust architecture, explicitly referencing NIST's guidance. The Office of Management and Budget turned that direction into specific requirements in memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, issued on 26 January 2022. It set agencies a deadline of the end of fiscal year 2024 to meet a series of goals. Several of them are directly about replacing the VPN model. Agencies were told to use enterprise-managed identities with phishing-resistant multi-factor authentication, to maintain a complete inventory of devices and detect and respond to incidents on them, to treat internal networks as untrusted, and to begin making internal applications safely accessible over the internet rather than relying on network-level access. The memorandum's language about applications was notable for its directness: agencies were to operate on the assumption that their networks and perimeters had been compromised, and to treat each application as internet-facing for the purposes of security testing. The Department of Defense published its own Zero Trust Strategy in November 2022, setting a target level of maturity for the department to reach by fiscal year 2027 and defining a large catalogue of capabilities and activities. The defence strategy is more prescriptive than most organisations will need, but its structure, which pairs a target state with a measurable set of steps, is a sound model for any programme. The yardstick: CISA's Zero Trust Maturity Model Frameworks that only describe an end state are hard to manage against. CISA's Zero Trust Maturity Model was designed to fill the gap by describing intermediate stages. Version 1.0 was released for comment in 2021; version 2.0 followed in April 2023. The model organises capabilities into five pillars, Identity, Devices, Networks, Applications and Workloads, and Data, and three cross-cutting capabilities that span them: Visibility and Analytics, Automation and Orchestration, and Governance. For each, it describes four stages of maturity: Traditional, Initial, Advanced and Optimal. Version 2.0 added the Initial stage, recognising that most organisations need a recognisable first step between where they are and where the documents say they should end up. The descriptions are qualitative: for identity, for example, maturity progresses from static passwords and manual provisioning toward phishing-resistant authentication, automated lifecycle management and continuous validation of identity throughout a session. For an architect planning a VPN replacement, the maturity model is useful less as a scorecard than as a reminder of dependencies. ZTNA lives mostly in the Networks and Applications pillars, but it draws its decisions from Identity and Devices and reports into Visibility and Analytics. An organisation that buys a sophisticated proxy while remaining at the Traditional stage for identity and devices has bought an enforcement point with nothing reliable to enforce. Table 1 sets the principal sources side by side, because practitioners are constantly asked which of them "the requirement" comes from. Table 1. Principal sources of zero trust guidance. Source Year Issued by What it contributes Jericho Forum commandments 2007 The Open Group forum Named de-perimeterisation; security close to data No More Chewy Centers 2010 Forrester (Kindervag) The term "zero trust"; least privilege between zones BeyondCorp papers 2014-2018 Google Working design: device inventory, access proxy, no privileged network SP 800-207 2020 NIST Neutral definition, seven tenets, PE/PA/PEP model M-22-09 2022 US OMB Federal goals and FY2024 deadline; apps over the internet Zero Trust Maturity Model v2.0 2023 CISA Five pillars, four maturity stages SP 1800-35 2025 NIST NCCoE Nineteen example builds with commercial products What the frameworks do not say Because these documents are cited so often in sales material, it is worth noting a few things they do not claim. None of them requires a particular product, vendor or category. SP 800-207 is explicit that zero trust is a set of principles and that an enterprise will reach it through a combination of existing and new components. A vendor that describes its product as "NIST 800-207 compliant" is making a marketing statement, since the publication contains no compliance test. What an architect can reasonably ask is how a product implements the logical components the publication describes: where the policy decision is made, where it is enforced, and which signals feed it. None of them says that the network no longer matters. SP 800-207 describes micro-segmentation and network-based enforcement as legitimate approaches, and CISA's model keeps Networks as a pillar. What changes is the network's role. It stops being a source of trust and becomes one more place where policy can be enforced and traffic observed. Encrypting internal traffic, segmenting environments and monitoring flows remain valuable; they simply cannot substitute for identity and device evidence. None of them treats zero trust as a one-time project with an end date. The maturity model's highest stage is described in terms of continuous, automated adjustment, and M-22-09's deadline applied to a set of initial goals, not to a finished state. The useful way to read these documents is as a direction of travel and a vocabulary for measuring progress. And none of them claims that zero trust prevents all compromise. SP 800-207 frames the goal as minimising uncertainty and limiting the impact of breaches, starting from the assumption that the network is already hostile. That is a more modest and more defensible promise than the one often made on its behalf, and it is the promise against which a ZTNA deployment should be judged. What the history teaches Three lessons stand out from this lineage, and each recurs in later chapters. The first is that zero trust was never primarily a networking idea, even when it was framed in networking terms. The common thread from Jericho to SP 800-207 is the removal of implicit trust, and implicit trust is granted whenever a decision depends on location rather than evidence. Network segmentation is one way to reduce it; identity-aware access is another and, for user access to applications, usually the more effective. The second is that the working implementations all began with inventory. BeyondCorp's device database and user database came before the proxy. M-22-09's goals begin with identity and devices. The maturity model makes the same point by placing those pillars first. Buying the enforcement point first is the most common mistake in ZTNA programmes, and history explains why it fails. The third is that migration is slow and must be measured. Google described its move as a multi-year effort, managed by watching which traffic still depended on the old privileged network and moving it piece by piece. Federal agencies did not all meet the M-22-09 goals by the end of fiscal year 2024, and the memorandum's authors had anticipated a long journey. There is no shortcut, but there is a sensible order of work, and the next two chapters cover its foundations: identity and devices. Chapter 3: Identity as the Control Plane If network location no longer decides who gets in, something else must. In every practical zero trust architecture, that something is identity: a verified answer to the question of which person, or which service, is making a request. Identity is not the only input to an access decision, but it is the one without which no other input means anything. A healthy, fully patched laptop operated by an attacker is still an attacker. This chapter explains what it takes for identity to bear that weight: a single authoritative source, authentication that cannot easily be phished or replayed, and verification that continues for the life of a session rather than ending at login. One source of truth The first requirement is mundane and frequently unmet. An organisation must know, in one place, who its users are. In many enterprises identity is scattered. There is an on-premises directory, usually Microsoft Active Directory, built up over twenty years. There may be a cloud identity provider adopted for software-as-a-service sign-on. Individual applications keep their own local accounts. The VPN may authenticate against yet another store, sometimes a RADIUS server or the appliance's own local database. Contractors may exist only in a spreadsheet kept by the procurement team. The Colonial Pipeline incident turned on exactly this fragmentation. The compromised account belonged to the VPN, it was described as a legacy account no longer meant to be in use, and the multi-factor protection that applied elsewhere did not apply to it. A single authoritative identity provider, tied to the HR system so that departures disable access everywhere at once, would not guarantee such an account never exists. It would make it far harder for one to survive unnoticed. In a ZTNA architecture, the identity provider, often abbreviated IdP, is the system that authenticates users and asserts their identity and attributes to other systems. The ZTNA broker trusts the IdP's assertions, typically conveyed through the federation standards SAML or OpenID Connect, and uses them in its access decisions. Applications behind the broker can also consume the same assertions for their own authorisation. The practical consequences are significant. • Lifecycle becomes enforceable. When a person joins, moves or leaves, the change is made once, ideally driven automatically from the HR system of record, and flows to every access decision. Provisioning standards such as SCIM let the IdP create and remove accounts in downstream applications. • Attributes become policy inputs. Department, role, employment type, manager, location and clearance can all be asserted by the IdP and used by policy. A rule that grants access to "full-time employees in the finance department" depends on those attributes being accurate, which in turn depends on a well-run source of truth. • Third parties can be handled honestly. Contractors and partners can be represented as identities with their own attributes, sponsors and expiry dates, or federated from the partner's own IdP, rather than being given generic shared accounts or VPN credentials. Non-human identities deserve the same discipline. Service accounts, API keys, automation credentials and the identities of workloads in cloud platforms frequently outnumber human users, and they are often over-privileged, long-lived and poorly tracked. ZTNA as described in this booklet concerns user access to applications, but the same principle applies: an automated process should authenticate with a credential tied to a known workload, be granted only what it needs, and be visible in the same inventory. Authentication that survives phishing The second requirement is that authentication must be hard to steal. For most of the past two decades the answer was "add a second factor", and adding any second factor is a large improvement over a password alone. But not all factors resist modern attacks equally, and the distinction matters enormously in an architecture that places so much weight on identity. Consider the common factors in turn. Codes sent by SMS can be intercepted through SIM-swapping or captured by a fake login page that relays them to the real one in real time. One-time codes from an authenticator app resist SIM-swapping but are just as vulnerable to real-time relay: the user types the code into a convincing fake page, and the attacker immediately types it into the real one. Push notifications, in which the user approves a prompt on their phone, introduced their own weakness. Attackers who already held a password learned to trigger prompt after prompt until a tired or confused user approved one, a technique called push bombing or MFA fatigue. Adding number matching, where the user must type a number shown on the login screen into the app, reduces but does not eliminate the risk, since a relayed login page can display the number too. The common weakness is that the user is the component that decides which site is genuine, and users can be fooled. Adversary-in-the-middle phishing kits that proxy the real login page and capture both the credential and the resulting session cookie are widely available and cheap. Against them, the only robust defence is authentication in which the cryptography itself checks the site. That is what phishing-resistant authentication means. The main forms are the FIDO2 and WebAuthn standards, used by hardware security keys and by platform authenticators built into modern laptops and phones, which are now commonly marketed to consumers as passkeys; and certificate-based authentication using smart cards, such as the Personal Identity Verification cards used across the US federal government. In FIDO2, the authenticator holds a private key that is bound to the specific website origin at registration. When a user tries to sign in, the browser tells the authenticator which origin is asking, and the authenticator will only sign a challenge for the origin it registered with. A lookalike domain gets nothing, no matter how convincing it looks to the user. M-22-09 required federal agencies to adopt phishing-resistant multi-factor authentication for exactly this reason, and CISA has repeatedly urged the same for private organisations. For architects, three practical points follow. First, phishing-resistant authentication has to cover recovery and enrolment, not only daily sign-in. If a user who loses a security key can get a new one by calling the help desk and answering a few questions, the strength of the key is irrelevant to an attacker willing to make a phone call. Several high-profile intrusions since 2022, including the September 2023 attacks on the casino operator MGM Resorts attributed to the group known as Scattered Spider, have relied on persuading help-desk staff to reset credentials or enrol a new device. Recovery procedures need identity proofing proportionate to the access being restored, such as video verification against a known photograph, or approval by a manager through a separate channel. Second, rollout is a logistics project. Hardware keys must be bought, distributed and registered; platform authenticators depend on device models and operating system versions; some users will have accessibility needs; and legacy applications that only understand passwords must be fronted by something that does modern authentication on their behalf, which is one of the services a ZTNA proxy provides. Third, the strength of authentication should be visible to policy. A good IdP records how a user authenticated, and a good ZTNA policy can require phishing-resistant authentication for sensitive applications while accepting weaker methods, for a period, for low-risk ones. From login to continuous verification The third requirement is the one that most clearly separates zero trust from a well-run VPN. Authentication at login, however strong, tells you who someone was at a moment in the past. Sessions last hours. In that time a laptop can be infected, a token can be stolen, a user can be terminated, or a session can be hijacked from a different country. SP 800-207's sixth tenet calls for a constant cycle of re-evaluation, and CISA's maturity model describes the optimal identity stage in terms of continuous validation throughout the session. Session theft is the threat that makes this necessary. After a user authenticates, the IdP and the applications issue tokens or cookies that represent the authenticated session. Whoever holds the token is treated as the user. Citrix Bleed, described in Chapter 1, leaked such tokens from VPN appliance memory. Information-stealing malware on endpoints harvests browser cookies in bulk and sells them on criminal markets. In October 2023 the identity provider Okta disclosed that an attacker had accessed its customer support system and obtained files that customers had uploaded for troubleshooting; some of those files, browser archives captured for diagnosis, contained live session tokens, which the attacker used against several customers. Phishing-resistant authentication does not help against a stolen token, because the token is what you get after authentication succeeds. Continuous verification attacks the problem from several directions at once. Short-lived tokens and frequent re-evaluation. If tokens expire quickly and must be refreshed through the IdP, each refresh is an opportunity to re-check the user's status, the device's posture and the risk signals. The trade-off is friction and load: refreshing too often annoys users and strains systems, so the art is to refresh silently where possible and to prompt for re-authentication only when something has changed. Binding tokens to devices. A token that can be used from any machine is valuable to a thief. A token that is cryptographically bound to a key held in the original device's secure hardware is not, because the thief cannot prove possession of the key. Several approaches exist, including mutual TLS with device certificates, in which the device presents a certificate during the connection, and newer mechanisms that bind browser session cookies to device keys. Token binding is one of the most effective defences against session theft, but support across browsers, applications and identity providers is still uneven, so architects must check what their chosen components actually enforce. Shared risk signals. Access decisions get better when the systems that observe risk can tell the systems that grant access. If the endpoint detection tool finds malware on a laptop, or the IdP sees a sign-in for the same user from a distant country an hour after one from the office, the ZTNA broker should learn about it and revoke or restrict sessions immediately rather than at the next token refresh. The OpenID Foundation's Shared Signals Framework, with its Continuous Access Evaluation Profile, usually shortened to CAEP, and its Risk Incident Sharing and Coordination profile, standardises how such events are exchanged between providers. Large platforms have built their own versions, such as continuous access evaluation in Microsoft's Entra ID, which lets some services revoke sessions promptly when an account is disabled or a high-risk event is detected. Where standards are not supported, integrations are typically built through vendor APIs. Behavioural and contextual signals. Location, time of day, the network a request comes from, and patterns of activity can all feed a risk score. These signals are useful but noisy. "Impossible travel" alerts are confounded by mobile networks and consumer VPNs; unusual hours are normal for on-call engineers. Context is best used to trigger step-up authentication or closer monitoring rather than outright denial, unless the signal is unambiguous. A single scenario, played out under two designs, shows why these mechanisms matter together. A finance analyst downloads what appears to be an invoice and unknowingly runs information-stealing malware. Within minutes, the malware has copied every cookie and session token from the analyst's browser and sent them to a server controlled by the attacker, who sells them in a bundle with thousands of others. Under a conventional design, the buyer imports the cookies into their own browser and visits the company's applications. Each application sees a valid session token, issued after a perfectly good multi-factor login that morning, and lets them in. Nothing about the attacker's machine is checked, because nothing was ever checked after login. The analyst's sessions remain valid until they expire, which for many applications means a working day or longer, and for some long-lived refresh tokens, weeks. Under a design built for continuous verification, the same purchase is worth far less. The session tokens are bound to a key held in the analyst's laptop's secure hardware, so the attacker's browser cannot present the proof that must accompany them, and the requests are refused. Even where some application does not support binding, the ZTNA broker in front of it requires a device certificate that the attacker does not possess. Meanwhile the EDR tool on the analyst's laptop has flagged the malware, and its alert is shared with the identity provider and the broker, which revoke the analyst's sessions and restrict the laptop to a remediation portal until it is cleaned. The analyst is asked to sign in again, from a healthy device, with a passkey. The window during which the stolen tokens had any value is measured in minutes, and they never worked from the attacker's machine at all. No single control in the second design is exotic. The difference is that they are connected, and that each of them assumes the one before it might have failed. Privileged identities Administrators deserve separate treatment because the access they hold is so much greater. In the VPN model, an administrator typically connected to the VPN and then reached management interfaces, SSH or remote desktop sessions across the network, often using standing privileges that existed all the time whether or not they were being used. In a zero trust model, administrative access should be both more strongly authenticated and less persistent. The practices that matter are well established. Administrators should use separate privileged accounts, distinct from the accounts they use for email and browsing, which reduces the chance that a phishing email or malicious download compromises a powerful identity. Privileged access should be granted just in time, for a defined period and purpose, ideally through an approval workflow, rather than held permanently. Sessions to administrative interfaces should be brokered through the same ZTNA or a dedicated privileged access gateway, recorded, and attributable to an individual rather than a shared account. And privileged access should require the strongest device posture as well, which in many organisations means a dedicated, hardened administrative workstation. ZTNA makes these controls easier to implement because the broker already sits in the path between the administrator and the resource. A rule can require that SSH access to production servers is permitted only to members of the operations group, with phishing-resistant authentication, from a privileged access workstation, during an approved change window. In the VPN model, enforcing the same rule meant coordinating the VPN, the network firewalls, a jump host and the change system, and the gaps between them were where the attackers walked through. Before turning to devices, one boundary needs marking. It is worth being clear about what identity cannot do. A verified identity tells you who is acting, not whether they should be doing what they are doing. An authorised employee who decides to steal data, or who is coerced into helping an attacker, passes every identity check. A compromised device operated by a genuine user, with the malware riding the user's legitimate session, passes them too. That is why identity is necessary but not sufficient, and why the access decision must also weigh the device, which is the subject of the next chapter, and why policy must keep each identity's reach as narrow as the job allows, which is the subject of Chapter 6. Identity is the control plane of zero trust in the sense that every decision is anchored to it. But a control plane is only as trustworthy as its inputs. The investment in a single authoritative source, in phishing-resistant authentication with equally strong recovery, and in continuous verification of sessions is the foundation on which a ZTNA deployment either stands or falls. Hashtags: #ZeroTrustNetworkAccess #ZTNA #CorporateVPN #VPNReplacement #ZeroTrustArchitecture #IdentityAwareAccess #ApplicationLevelAccess #LeastPrivilege #ContinuousVerification #IdentityProvider #DevicePosture #IdentityAwareProxy #PolicyEngine #PolicyEnforcementPoint #PhishingResistantMFA #FIDO2 #WebAuthn #ContinuousAccessEvaluation #SessionBinding #LateralMovementPrevention #ApplicationSegmentation #RemoteAccessSecurity #ZeroTrustMigration #BeyondCorp #FutureOfZeroTrustAccess

Download the Book (PDF): Introduction: The Wall That Wasn't There For most of the history of enterprise computing, security had a shape, and the shape was a wall. Inside the wall sat the trusted things: employees, their workstations, the file servers, the databases, the printers that never quite worked. Outside the wall sat everyone else, a hostile and anonymous internet from which attacks arrived. The job of the security team was to build the wall high, watch the one gate carefully, and decide who could pass through it. This was the perimeter, and it organized not just the technology but the entire way people thought about trust. To be inside was to be trusted. To be outside was to be suspect. It was always something of a fiction, but for a long time it was a useful one. When a company's computing lived in a single building, when employees worked from desks wired into the corporate network, when applications ran on servers the company owned and could point to, the wall corresponded to something real. The network edge was a genuine boundary, and defending it was a coherent strategy. Firewalls grew more sophisticated, intrusion detection systems watched the gate, and virtual private networks extended the inside to the occasional traveler who needed to reach back in. The model had a logic, and the logic held. Then the ground shifted under it. Applications moved to the cloud, which meant the things worth protecting were no longer behind the wall at all; they sat in data centers owned by Amazon, Microsoft, and Google, reachable from anywhere. Employees moved too, first to laptops and phones, then, decisively, to their homes, where the corporate network was a tunnel rather than a place. Software stopped being something installed on a server and became a web of services calling other services across the public internet. The supply chain lengthened until a company's security depended on the security of vendors it had never audited and could not see. By the time most organizations noticed, the inside and the outside had thoroughly mixed. The wall still stood, but the things it was built to protect had walked out through the gate, and the attackers had learned to walk in behind them. The deeper problem was never the wall's height. It was the assumption written into its foundation: that location implies trust. A perimeter model grants broad freedom to anything it believes is inside. An attacker who steals a valid password, compromises a single laptop, or slips in through a vulnerable web application does not face a second wall once past the first. They inherit the trust of the inside. This is why the great breaches of the past fifteen years follow the same grim choreography. An intruder gains an initial foothold — a phished credential, an unpatched server, a malicious email attachment — and then moves laterally, host to host, account to account, because inside the perimeter there is nothing to stop them. The 2013 Target breach began with a heating-and-cooling contractor's stolen credentials and ended at the point-of-sale terminals. The 2020 SolarWinds compromise began with poisoned software updates trusted precisely because they came from a trusted vendor. In each case the perimeter did its narrow job and the organization fell anyway, because the one thing the perimeter could not do was defend the inside against the inside. Zero trust is the name given to the correction. The phrase is unfortunate in some ways — it suggests a posture of paranoia, a refusal to trust anyone, which is not quite the point and has launched a thousand misleading marketing campaigns. What zero trust actually proposes is narrower and more interesting. It proposes that trust should never be granted on the basis of location, and never granted permanently. Instead, trust should be earned continuously, on every request, by verifying who is asking, what device they are asking from, whether that device is healthy, what they are trying to reach, and whether the whole pattern is consistent with normal and authorized behavior. The question a zero trust system asks is not "are you inside?" but "should this specific identity, on this specific device, be allowed to do this specific thing, right now?" And it asks the question again the next time, and the time after that. This is a profound change, and it is worth being honest about how profound. Zero trust is not a product you can buy, though a great many vendors would like to sell you one. It is not a project with an end date, though organizations keep trying to manage it as one. It is an architecture and, beneath the architecture, a principle: that implicit trust is the vulnerability, and that the cure is explicit, continuous, context-aware verification of every access decision, enforced as close as possible to the resource being protected. Everything else — the identity systems, the device posture checks, the micro-segmentation, the policy engines — is machinery in service of that principle. This booklet is an argument for that principle and a practical guide to living by it. It is written for people who have to make zero trust real in organizations that already exist, with their accumulated systems, their political constraints, and their limited budgets — not for a greenfield built by idealists. The early chapters make the case: why the perimeter failed, what zero trust actually asserts, and why identity rather than network location has become the thing security must hang on. The middle chapters work through the pillars — identity, devices, networks, workloads, and the particular demands of multi-cloud environments and a workforce that may never again sit together in one building. The final chapters are about the hard part, which is not understanding zero trust but implementing it: the maturity path, the sequencing, the mistakes that are easy to make, and the governance without which the whole thing dissolves into a collection of half-finished pilots. A word about who this is for and what it assumes. It assumes a reader who is technically literate but not necessarily a security specialist — a leader who must decide whether and how to pursue zero trust, an engineer who will have to build parts of it, a professional in an adjacent field who needs to understand what their security colleagues are talking about and why it matters. It does not assume prior knowledge of any particular product or framework, and it defines its terms as it goes. What it does assume is that the reader wants to understand the idea well enough to act on it, rather than merely to recognize the phrase, and so it spends its effort on the reasoning behind each element of the architecture rather than on the configuration details that any particular tool will document better than a book can. The aim is to leave the reader able to tell the genuine article from the marketing, to sequence the work sensibly, and to recognize the failure modes before falling into them. A warning and a reassurance, both earned by watching organizations attempt this. The warning: zero trust done badly is worse than the perimeter it replaces, because it adds cost and friction without closing the gap the perimeter left open. A company that buys an identity product, declares victory, and leaves its internal network flat and permissive has not adopted zero trust; it has bought a login screen. The reassurance: zero trust done incrementally, with a clear understanding of what it is actually for, is achievable by ordinary organizations, and every honest step toward it reduces risk whether or not the journey is ever declared complete. You do not have to arrive to benefit from walking. But you do have to understand where you are going, and that is where we begin. Chapter 1: The End of the Castle The metaphor security people reach for most often is the medieval one. A castle with thick walls, a moat, a single guarded drawbridge. Everything valuable kept inside; everything dangerous kept out. The image is useful because it captures how perimeter security actually felt to the people who practiced it, and it is instructive because it captures, just as clearly, why the model eventually failed. Castles fell too — not usually because the walls were breached by force, but because someone opened a gate from the inside, or because the thing worth stealing had already been moved beyond the walls, or because the enemy simply walked in dressed as a friend. The perimeter was never as solid as it looked, and the things that defeated it were rarely the things it was built to stop. To understand why organizations are dismantling a model that served them for decades, it helps to understand what that model assumed, why those assumptions were once reasonable, and how each of them quietly stopped being true. How the perimeter was supposed to work The perimeter model rests on a single structural idea: that the network can be divided into a trusted interior and an untrusted exterior, with a controlled boundary between them. In its classic form, the boundary was enforced by a firewall — a device that inspected traffic crossing between networks and permitted or denied it according to rules. Traffic originating inside was generally trusted and allowed out. Traffic originating outside was scrutinized, and most of it was refused. The firewall was the drawbridge, and for a time it was a good one. Around the firewall grew a whole ecosystem of boundary defenses. Intrusion detection and prevention systems watched the crossing traffic for signatures of known attacks. Web proxies filtered what employees could reach. Email gateways scanned attachments. Demilitarized zones — carefully fenced subnetworks — held the servers that genuinely needed to face the public internet, keeping them separate from the sensitive interior. This layered boundary was often called defense in depth, though in practice the depth was concentrated almost entirely at the edge. Once a connection made it past the perimeter, it entered a soft interior where controls were sparse and trust was abundant. That abundance of interior trust was the whole point. The reason to defend the boundary so fiercely was precisely so that the inside could be a place of frictionless collaboration. Inside the wall, a workstation could reach a file server without re-authenticating, an application could call a database without proving its identity each time, an administrator could move between systems freely. The perimeter bought the organization an interior where work could happen without constant interruption. Security lived at the edge so that productivity could live everywhere else. For the computing environment of roughly 1995 to 2010, this was a defensible arrangement. The assets were inside: the mail server, the file shares, the line-of-business applications all ran on hardware the company owned, in buildings the company controlled. The users were inside: employees sat at desks, physically present, connected by cable to the corporate LAN. The boundary was real: there was an actual, identifiable network edge where the company's infrastructure met the outside world, and a firewall could be placed there. When all three of these conditions held, the perimeter corresponded to something true about the world, and defending it was a coherent strategy. The model did not fail because it was foolish. It failed because the world it described disappeared. The assets left the building The first assumption to collapse was that the valuable things lived inside. Cloud computing changed this not gradually but comprehensively. When an organization moves its email to a hosted service, its customer records to a software-as-a-service platform, its applications to infrastructure rented from a cloud provider, the assets it most needs to protect are no longer behind the firewall. They sit in data centers the organization does not own, reachable over the public internet, by design, from anywhere. This is not a problem that better perimeter defenses can solve, because there is no longer a single perimeter around the assets. A company might use dozens or hundreds of cloud services, each with its own boundary, its own access controls, its own idea of who is allowed in. The corporate firewall sees none of this traffic, because the traffic never touches the corporate network. An employee working from home, logging into a cloud application, is having a conversation the perimeter cannot hear. The wall still stands around a building that is increasingly empty. Some organizations tried to force the new model back into the old shape — routing all cloud traffic back through the corporate network so the perimeter could inspect it, a pattern called backhauling or hairpinning. It works, after a fashion, but it is slow, expensive, and fights against the whole reason the cloud was attractive. Routing a video call from a home office in one city, back to a corporate data center in another, and out again to a cloud server in a third, adds latency and cost to punish the user for the organization's nostalgia. Backhauling was the perimeter's attempt to pretend nothing had changed, and it did not survive contact with a remote workforce. The users left too The second assumption — that users sit inside — eroded over years and then collapsed in weeks. Laptops made employees mobile within the building, then beyond it. Smartphones put corporate email in every pocket. The traditional answer was the VPN, the virtual private network, which extended the trusted interior out to a remote device by building an encrypted tunnel back to the corporate network. Through the VPN, a laptop in a hotel room became, as far as the network was concerned, a device on the inside. This was a reasonable patch when remote access was occasional. It became a liability when remote access became the norm. The VPN embodies the perimeter's central flaw in concentrated form: it grants broad network access on the basis of a single authentication event. Once a device connects through the VPN, it is inside, with all the trust that implies, often able to reach large swaths of the internal network. A VPN authenticates the connection at the start and then, in the classic configuration, trusts it for the duration. If the credentials used to establish the connection were stolen, or the connecting device is compromised, the VPN faithfully extends the interior's trust to an attacker and asks no further questions. When the events of 2020 sent entire workforces home at once, organizations discovered what it meant to have the perimeter model's assumptions inverted overnight. The exception — remote access — became the rule. VPN concentrators strained under loads they were never sized for. And every remote laptop, many of them personal devices on home networks shared with family members and smart televisions and whatever else, became a potential doorway into the trusted interior. The perimeter had assumed users were inside. Now almost none of them were, and the model's response to a remote user was simply to pretend they were inside anyway, which is to say, to extend the very trust that was the problem. The lateral movement problem The deepest flaw, though, was not about where assets or users lived. It was about what happened after an attacker got in — and attackers always, eventually, get in. The perimeter model invests nearly everything in prevention at the boundary and leaves the interior comparatively undefended. This means the consequences of a single successful intrusion are catastrophically out of proportion to the intrusion itself. Consider the shape of a typical serious breach. An attacker obtains an initial foothold. The method hardly matters: a phishing email that harvests a password, a vulnerability in an internet-facing server, a malicious document opened by an unwary employee, a contractor's compromised credentials. This foothold gives the attacker a single point of presence inside the perimeter — one account, one host. In a well-designed system, that should be a contained problem. In a perimeter-based system, it is the beginning of the end, because inside the wall there is little to stop the attacker from spreading. What follows is called lateral movement, and it is the heart of nearly every major breach. From the initial foothold, the attacker explores the internal network, which the perimeter has helpfully left flat and permissive. They harvest additional credentials from the compromised host — passwords cached in memory, authentication tokens, keys left in configuration files. They use those credentials to reach other systems, because inside the perimeter, systems trust one another. They escalate privilege, hunting for administrative accounts that can go anywhere. They locate the domain controllers that govern identity for the whole organization, and if they reach those, the game is effectively over: control of the identity system is control of everything. Throughout this process, the attacker is behaving, from the network's point of view, like a legitimate insider, because the network has no way to distinguish a stolen identity used maliciously from a real one used normally. The Target breach of 2013 is the canonical teaching case. The attackers entered through credentials stolen from a third-party vendor that provided heating and refrigeration services — a vendor with network access it did not need to the degree it had. From that foothold, the attackers moved laterally across Target's internal network, which did not meaningfully separate the vendor-accessible systems from the payment infrastructure, and eventually reached the point-of-sale terminals, from which they exfiltrated tens of millions of payment card records. No wall was scaled by force. The perimeter did exactly what it was designed to do, and the breach happened in the space the perimeter was never designed to defend: the interior, where everything trusted everything. The 2020 SolarWinds compromise made the same point from a different angle. Attackers compromised the build process of a widely used network management product and distributed a malicious update to thousands of organizations. Those organizations installed it willingly, because it came from a trusted vendor through a trusted channel — and once installed, the compromised software ran inside the perimeter with the broad access that network management tools require. The trust that enabled the attack was not misplaced at the boundary; it was the implicit, standing trust granted to software and systems already inside. SolarWinds demonstrated that the supply chain is a path through the wall that the wall cannot see, and that interior trust, once an attacker is positioned to exploit it, is a gift. The economics that kept the wall standing If the perimeter's flaws were so structural, it is fair to ask why organizations clung to it for so long after the cracks were visible. The answer is partly economic and partly human, and it is worth understanding because the same forces resist the move to zero trust today. The perimeter was cheap in a particular way: it concentrated cost. One firewall, one set of boundary defenses, one place to watch, protected everything behind it. The alternative — verifying every request, segmenting every workload, assessing every device — distributes cost across the entire environment, and distributed cost is harder to justify in a budget cycle than a single appliance at the edge. The perimeter also concentrated expertise; a team could become expert in the boundary without understanding every system behind it. And it concentrated accountability; when the boundary was the defense, the boundary team was responsible, and everyone else could treat security as someone else's concern. These were real organizational conveniences, and they made the perimeter sticky well past the point where it worked. There was a deeper human factor too: the interior trust that the perimeter granted was not merely a security failure but a productivity feature that people valued. The frictionless inside — where systems talked to one another freely, where an administrator could move between hosts without re-proving themselves, where collaboration happened without constant interruption — was pleasant to work in, and dismantling it felt like imposing friction for its own sake. Every argument for zero trust has had to overcome the memory of how smooth the trusted interior was to inhabit, and every implementation that imposes friction carelessly revives the objection. Understanding that the perimeter persisted not out of ignorance but because it concentrated cost and maximized convenience is the first step toward making zero trust succeed where it so often stalls: by concentrating its own value visibly, distributing its friction thoughtfully, and never pretending that the smooth old interior had no appeal. Why patching the perimeter was not enough Faced with these failures, the industry's first instinct was to reinforce the existing model. Add more layers to the boundary. Deploy more sophisticated intrusion detection. Buy better threat intelligence. These efforts were not worthless — a well-defended perimeter is still better than an undefended one — but they could not address the structural problem, because the structural problem was not that the wall was too low. It was that the model concentrated defense at a boundary that no longer corresponded to the shape of the organization, and left trusted the interior where the real damage was done. You cannot patch your way out of a bad assumption. As long as the governing principle was "inside is trusted," every improvement to the boundary left the interior trust intact, and every attacker who got past the boundary — through phishing, through a vulnerability, through the supply chain, through a stolen VPN credential — inherited that trust in full. The organizations that understood this began to ask a different question. Not "how do we build a better wall?" but "what would security look like if we stopped assuming that location means trust at all?" That question is the beginning of zero trust. Its answer starts from a deliberately pessimistic premise: assume the attacker is already inside. Assume the network is hostile. Assume any given request might be malicious, any given credential might be stolen, any given device might be compromised. Then design a system that remains defensible under those assumptions — a system that verifies every request on its own merits, grants the narrowest access that will do the job, and never extends standing trust to anything on the basis of where it sits. The castle is gone. What replaces it is not a bigger castle but a different idea entirely: a world with no trusted interior, in which every door checks your credentials, every time, and opens only as far as it must. The chapters that follow describe how such a world is built, and the next one begins where it must — with what zero trust actually means, beneath the marketing. Chapter 2: What Zero Trust Actually Means The term "zero trust" has suffered the fate of every successful idea in technology: it has been borrowed, stretched, and emptied by people with something to sell. Walk a vendor exhibition and you will find firewalls, identity products, endpoint agents, network appliances, and cloud gateways all labeled zero trust, often with the implication that purchasing the item in question will deliver the thing. This is noise, and the first task in understanding zero trust is to filter it out. Zero trust is not any of those products. It is a set of principles about how access decisions should be made, and the products are, at best, instruments for enforcing those principles. The most authoritative plain statement of the principles comes from the United States National Institute of Standards and Technology, whose Special Publication 800-207, published in 2020, remains the reference text. It is worth taking seriously not because government documents are inherently wise but because this one is careful, vendor-neutral, and refreshingly free of the marketing instinct to oversimplify. What follows draws on its framing while translating it into working terms. The core idea, stated plainly Zero trust begins from an assumption about the environment: the network is hostile, and should be treated as hostile even when it is nominally the organization's own. There is no trusted zone. An attacker may already be present. A device on the corporate LAN deserves no more inherent trust than a device on a coffee shop's wireless. From this assumption follows the governing rule: no access is granted on the basis of network location, and no trust is granted permanently. Every request to access a resource is evaluated on its own, at the time it is made, against everything the system knows about the requester and the context. That evaluation considers, at minimum, the identity making the request and whether it has been authenticated strongly; the device the request comes from and whether that device is known, managed, and healthy; the resource being requested and the sensitivity of the operation; and whatever contextual signals are available — the time, the location, the pattern of recent behavior, the presence of anomalies. On the strength of that evaluation, the system grants access, denies it, or grants it conditionally, perhaps demanding additional authentication or limiting what can be done. And critically, the grant is not forever. Trust decays. The session is re-evaluated; the context is monitored; a change in circumstances can withdraw access that was granted a moment ago. The phrase that captures the operational discipline is "never trust, always verify," though a more precise version would be "never trust implicitly, always verify explicitly, and verify continuously." The enemy is implicit trust — trust granted automatically because of where something is, or because it authenticated once an hour ago, or because it is a type of system that has always been allowed to do a type of thing. Every instance of implicit trust is a place where a compromised identity or device can operate unchallenged. Zero trust is the systematic replacement of implicit trust with explicit, per-request, context-aware verification. The tenets NIST frames zero trust through a set of tenets — assertions that, taken together, define what it means for an architecture to be genuinely zero trust rather than merely marketed as such. They are worth walking through, because each one rules out a common half-measure. First, all data sources and computing services are treated as resources to be protected, not just the obvious crown jewels. A zero trust architecture does not defend only the database of customer records; it treats every service, every data store, every workload as something that requires an access decision. This matters because attackers pivot through the overlooked. The forgotten internal tool with weak controls is the stepping stone to the asset that matters. Second, all communication is secured regardless of network location. There is no "internal" traffic that gets a pass because it never leaves the building. Traffic between two servers in the same data center is authenticated and encrypted just as traffic from a remote laptop would be. The network's location confers no exemption, because the network's location confers no trust. Third, access to individual resources is granted on a per-session basis, and trust is evaluated before each session, not inherited from a previous one. Authenticating to one resource does not grant access to another. Each access is its own decision. Fourth, access decisions are determined by dynamic policy that takes account of multiple signals — identity, device state, behavioral attributes, environmental factors — rather than by static rules that ask only whether an address is on an allowed list. The policy is a function of context, and context changes. Fifth, the organization monitors the integrity and security posture of all its assets. No device is trusted on faith. A device's right to access resources depends on its measurable state: is it patched, is it running the required protections, has it been tampered with? Posture is continuously assessed, and a device that falls out of compliance loses access. Sixth, authentication and authorization are dynamic and strictly enforced before access is allowed — and this is a continuous cycle, not a one-time gate. The system is constantly scanning, assessing, re-evaluating, and adjusting. Access granted is access that can be revoked the moment the signals change. Seventh, the organization collects as much information as it can about the current state of assets, network, and communications, and uses it to improve its security posture over time. Zero trust is data-hungry by nature, because good access decisions require good information, and the quality of the decisions is bounded by the quality of the signals feeding them. No single product satisfies these tenets. They describe an architecture, and the architecture is assembled from many components working in concert. Which brings us to how the decision actually gets made. The machinery: policy decision and policy enforcement At the center of any zero trust architecture is a conceptual split between deciding and enforcing, and understanding this split is the key to understanding how the whole thing works. The decision is made by what NIST calls the policy decision point, which it further divides into two cooperating parts. The policy engine is the brain: it takes in all the signals — the authenticated identity, the device posture, the sensitivity of the requested resource, the contextual risk — and runs them against the organization's policy to reach a verdict. Grant, deny, or grant with conditions. The policy administrator is the hand that carries out the verdict: it establishes or terminates the connection, issues or revokes the credentials or tokens that the session needs, and communicates the decision to the component that will enforce it. That component is the policy enforcement point. It sits in the path between the requester and the resource, and it is where the decision becomes real. The enforcement point allows the connection the policy engine approved, blocks the one it refused, and tears down a session when told the verdict has changed. It is a gate, but a gate that makes no decisions of its own; it simply enforces what the decision point tells it. The elegance of this separation is that it concentrates intelligence in one place and distributes enforcement everywhere it is needed. There can be many enforcement points — in front of applications, embedded in network fabric, running as agents on devices, operating as cloud gateways — all taking their orders from a central decision-making capability that has the full picture. The enforcement points do not need to be smart; they need to be everywhere, as close to the protected resources as possible. The intelligence lives in the policy engine, which is where the organization's security logic is expressed and where the signals converge. Feeding the policy engine is a surrounding ecosystem of signal sources, and the richness of this ecosystem largely determines how good the decisions can be. Identity and access management systems supply the authenticated identity and its entitlements. Device management and endpoint protection systems supply device posture. Threat intelligence feeds supply knowledge of known-bad indicators. Security information and event management platforms supply behavioral context. Data classification systems supply the sensitivity of the resource. The policy engine is only as wise as the signals it receives, which is why the later tenets insist on collecting so much information: the data is not an afterthought but the raw material of every decision. What zero trust is not Because the term is so abused, it is worth stating plainly what zero trust does not mean, so that the genuine article can be recognized. Zero trust is not a product. No single purchase delivers it, and any vendor claiming otherwise is selling a component and calling it the whole. The components matter, but a company can own every one of them and still have a perimeter architecture if the components are not wired together to make continuous, per-request access decisions. Zero trust is not the same as a particular technology, though several technologies are commonly involved. Multi-factor authentication is important to zero trust but is not zero trust; an organization can require strong authentication and then grant broad standing access, which satisfies the letter of "verify" while violating the spirit of "never trust." Micro-segmentation is a powerful zero trust technique but is not, by itself, zero trust; you can segment a network and still make access decisions on static rules that ignore identity and context. Zero trust network access, the technology that increasingly replaces the VPN, is an enforcement pattern that serves zero trust but is not coextensive with it. Each of these is an instrument. The architecture is the orchestra. Zero trust is not about eliminating trust, despite the name. Some trust must exist — the system must trust its own policy engine, its identity provider, its sources of truth, or it could make no decisions at all. The point is not zero trust in the literal sense of trusting nothing, but zero implicit trust: no trust granted automatically, by default, on the basis of location or prior authentication or category. Trust still exists, but it is always explicit, always earned, always scoped, and always revocable. And zero trust is not a project with a finish line. This is perhaps the most commonly misunderstood point, and the most consequential. Organizations keep trying to manage zero trust as an initiative with a budget and an end date, and then declare it complete when the identity product is deployed or the VPN is retired. But zero trust is a posture that must be maintained continuously, because the environment, the threats, and the organization itself keep changing. The verification is continuous; the monitoring is continuous; the policy evolves. Zero trust is a way of operating, not a state to reach. An organization does not become zero trust and then stop; it operates in a zero trust manner, indefinitely, or it drifts back toward implicit trust. A decision, walked through It helps to see the machinery operate on a single concrete request, because the abstraction of policy engines and enforcement points becomes clearer when watched in motion. Suppose an employee named in the organization's directory as a member of the finance team attempts, at eleven in the morning, to open a financial reporting application that holds sensitive quarterly figures. In a perimeter model, the relevant question would have been answered the moment she connected to the network: she is inside, so she may reach the application, and the application, seeing a connection from an internal address, serves it. Nothing else is asked. In a zero trust model, the request sets off a far richer evaluation. The enforcement point in front of the application intercepts the attempt and refers it to the policy engine rather than serving it. The policy engine assembles what it knows. From the identity system: this is a correctly authenticated identity, verified moments ago with a phishing-resistant factor, belonging to a current employee whose role includes access to financial reporting. From the device system: the request comes from a managed laptop, enrolled and identified, running current software with its protections healthy and no indication of compromise. From the context: the access is from the employee's usual location, at a normal hour, and fits her established pattern of behavior. The policy engine weighs all of this against the organization's policy for this sensitive application and reaches a verdict — grant — which the policy administrator carries out by establishing the session, and the enforcement point serves the application. Now change one fact and watch the decision change with it. Suppose the same identity, correctly authenticated, makes the same request — but from an unrecognized device, at three in the morning, from a country the employee has never worked from, minutes after a login from her usual city that is geographically impossible to reconcile with the new location. Every signal that was reassuring is now alarming. The policy engine, seeing a pattern consistent with a stolen credential being used by an attacker, does not simply grant access because the authentication succeeded. It can refuse outright, or demand a stronger re-authentication that an attacker holding only the password cannot satisfy, or grant only constrained access while flagging the session for investigation. The identity is the same; the context is not; and because zero trust decides on context rather than on the mere fact of authentication, the architecture catches what a perimeter model, and even a naive multi-factor deployment, would have waved through. This is what "dynamic policy evaluated continuously" means in practice, and it is why the surrounding ecosystem of signals matters as much as the authentication itself. Why identity carries the weight One implication of all this deserves to be drawn out now, because it shapes everything that follows. In a world with no trusted network location, the thing that access decisions must hang on is identity. If you cannot trust where a request comes from, you must be able to trust who is making it and what they are using to make it. Identity — of users, of devices, of workloads — becomes the primary axis of control, the new foundation on which access is built. This is sometimes summarized by saying that in zero trust, identity is the new perimeter, and while the phrase is a little too neat, it points at something true. The old perimeter was a place; the new one, if it can be called a perimeter at all, is an identity verified strongly enough and continuously enough to serve as the basis for access. Everything the perimeter used to do — distinguishing the trusted from the untrusted, deciding who gets in — now has to be done through identity and the context attached to it. That is a great deal of weight to place on identity, and it means that getting identity right is not one task among many in a zero trust architecture. It is the foundation, and the next chapter is devoted to it. Chapter 3: Identity as the New Perimeter If location can no longer tell you whom to trust, identity must. This is the hinge on which zero trust turns, and it changes the stakes of identity management entirely. In a perimeter model, identity was one control among several, and often not the strongest; the network did much of the work of keeping strangers out, and the login screen was a formality that happened once a day. In a zero trust model, identity is load-bearing. It is the thing every access decision depends on, the signal that must be trustworthy because so little else is. An organization that moves to zero trust without first getting identity right has built a house on sand. This chapter is about what "getting identity right" means when identity carries this much weight. It means strong authentication, but it means more than that. It means knowing who your identities are and governing what they can do. It means authenticating continuously rather than once. And it means extending the discipline of identity beyond human users to the machines, services, and workloads that increasingly make most of the requests in a modern environment. The password was never enough, and now it is dangerous Begin with the obvious weak point. For decades, the password was the primary proof of identity, and for decades it has been failing. Passwords are stolen in bulk through breaches of one service and reused against others, because people reuse them. They are harvested through phishing, extracted through malware, guessed when weak, and cracked when leaked in hashed form. The entire economy of credential theft — the marketplaces selling stolen logins, the tools for spraying common passwords across many accounts, the phishing kits that mimic login pages — exists because the password alone is a proof that attackers have learned to forge at scale. In a perimeter world, a stolen password was bad but bounded; the attacker still had to reach the network, and the interior controls might catch them. In a zero trust world, where identity is the perimeter, a stolen password that is the sole proof of identity is a catastrophe, because it is the key to everything the identity can reach. The first and most urgent task of identity in zero trust is therefore to make a stolen password insufficient on its own. That is the role of multi-factor authentication. Multi-factor authentication, and why not all of it is equal Multi-factor authentication requires more than one kind of proof: something you know (a password), something you have (a device or token), something you are (a biometric). The logic is that an attacker who steals one factor still lacks the others. This logic is sound, and multi-factor authentication is among the highest-value security controls an organization can deploy, foreclosing the large majority of credential-based attacks. But not all multi-factor authentication is equal, and the differences matter more as attackers adapt. The weakest common form sends a one-time code by text message. It is far better than a password alone, but it is vulnerable in ways that sophisticated attackers exploit. Codes can be phished — an attacker running a fake login page simply asks for the code along with the password and relays both to the real service in real time. Phone numbers can be hijacked through SIM-swapping, in which an attacker convinces a mobile carrier to move the victim's number to a device the attacker controls. Codes delivered through an authenticator application are better, resisting SIM-swapping, but they remain phishable: a user tricked into entering a code on a fraudulent page has handed it over just as surely. A particular failure mode deserves naming because it has become common: multi-factor fatigue, sometimes called push bombing. When the second factor is a push notification that the user simply approves, an attacker who has the password can trigger a flood of approval requests, gambling that the user, confused or worn down, will eventually tap approve to make the notifications stop. Several significant breaches have turned on exactly this. The lesson is that a second factor which can be satisfied by a tired human making a mistake is weaker than it looks. The strong form of multi-factor authentication is what the field calls phishing-resistant, and it is built on public-key cryptography rather than shared secrets. In this model, the user's device holds a private key that never leaves it; authentication proves possession of that key through a cryptographic exchange that is cryptographically bound to the specific website or service being accessed. Because the proof is bound to the real service's identity, it cannot be relayed to a fraudulent site — the fraudulent site has the wrong identity, and the cryptography refuses to cooperate. This is the principle behind hardware security keys and the newer passkeys that implement the same standards in a more usable form. Phishing-resistant authentication closes the gap that every phishable factor leaves open, and for the identities that matter most — administrators, privileged accounts, anyone whose compromise would be severe — it should be considered the baseline, not the aspiration. The direction of travel across the industry is toward eliminating the password entirely in favor of these cryptographic proofs, and zero trust architectures should lean into that direction rather than resist it. Knowing and governing your identities Strong authentication proves that an identity is who it claims to be. It says nothing about whether that identity should exist, or what it should be allowed to do. This is the domain of identity governance, and it is the part organizations most often neglect, because it is unglamorous and politically fraught. The foundational problem is that organizations accumulate identities and entitlements like sediment. People join and are granted access; they change roles and accumulate more access without shedding the old; they leave and their accounts linger, deprovisioned slowly or not at all. Contractors, partners, and service accounts proliferate. Over years, the result is a sprawling population of identities, many of them holding far more access than they need, some of them belonging to people who are gone, a few of them forgotten entirely. Each excess entitlement is a liability, because each is a path an attacker can use once they compromise the identity holding it. Each orphaned account is a door left unlocked. Zero trust depends on reversing this accumulation, and the governing principle is least privilege: every identity should hold the minimum access required to do its job, and no more. This is simple to state and genuinely hard to achieve, because it requires knowing what each identity actually needs — which is often unknown even to the identity's owner — and because reducing someone's access is the kind of change that generates complaints while preventing invisible disasters. The practical disciplines are regular access reviews, in which entitlements are re-justified or removed; automated provisioning and deprovisioning tied to authoritative records, so that access is granted and revoked as people join, move, and leave; and particular attention to privileged accounts, whose excessive power makes them the attacker's ultimate target. Privileged access deserves its own treatment, because administrative accounts are the keys to the kingdom and attackers hunt them relentlessly. The disciplines here include granting administrative rights only when needed and only for as long as needed — just-in-time access rather than standing privilege — so that there is no always-on administrator account for an attacker to steal. They include separating administrative identities from everyday ones, so that an administrator's routine email account, more exposed to phishing, is not also the account that controls the infrastructure. And they include watching privileged activity closely, because the use of high privilege is exactly where a compromise does the most damage and where anomalies are most worth catching. A case in the failure of the shared secret The abstract argument against passwords and shared secrets becomes vivid in the pattern of real breaches, which repeat the same lesson with such regularity that it has become a genre. Consider the general shape, assembled from many incidents rather than attributed to any single one, because the pattern is what matters and the pattern is universal. An attacker obtains a set of credentials — perhaps harvested from a breach of an unrelated service where an employee reused a password, perhaps phished through a convincing fake login page, perhaps bought in bulk from a marketplace that trades in stolen logins. The credentials belong to an ordinary employee with no special privileges, which is exactly why they were easy to obtain and exactly why their theft was not noticed. The attacker uses them to authenticate, and because the account is protected by a password alone or by a phishable second factor that the attacker also captured, the authentication succeeds. The attacker is now operating as a legitimate employee. From there the pattern unfolds along the lines the first chapter described, but the identity dimension is the thread that runs through it. The attacker, now inside as a real user, hunts for more credentials — those cached on the systems the compromised user could reach, those belonging to service accounts with their long-lived secrets written into configuration, those of administrators whose greater privilege is the real prize. Each credential harvested extends the attacker's reach, because each is a standing, reusable proof of identity that the systems accept without question. The escalation continues until the attacker reaches an account powerful enough to accomplish the goal, often an administrative account controlling the identity system itself, at which point they can grant themselves whatever access they lack. The entire progression is enabled by credentials that are shared secrets: stealable, reusable, long-lived, and accepted on presentation without regard to who is actually presenting them or from where. This is why phishing-resistant authentication, least privilege, short-lived credentials, and the governance of machine identities are not separate refinements but a single coordinated answer to a single coordinated attack. Each closes one of the doors the attacker walks through, and the breach pattern survives only as long as any of them is left open. Continuous authentication and the death of the standing session A perimeter model authenticates at the door and then, having admitted you, largely forgets about you until you leave. Zero trust cannot work this way, because a single authentication at the start of a session says nothing about what happens during it. The device may become compromised mid-session. The behavior may turn anomalous. The context may change in ways that should revoke the trust that was granted. So zero trust replaces the one-time gate with continuous evaluation. In practice this means that authentication and authorization are not events but ongoing conditions. The system watches the session for signals that the trust underlying it may no longer hold: a sudden change in location that is physically impossible given the last known location, a shift in device posture as protection is disabled or a vulnerability appears, a pattern of access that does not match the identity's normal behavior, the appearance of a known-bad indicator. When such signals arise, the system can respond proportionally — demanding re-authentication, stepping up to a stronger factor, limiting what the session can do, or terminating it outright. This is adaptive or risk-based authentication, and it is how the continuous tenet becomes real. The user experience of this, done well, is mostly invisible. A low-risk access from a known device in a normal context proceeds without friction; the system is confident and does not interrupt. Friction appears only when risk rises — a new device, an unusual location, an attempt to reach something sensitive — at which point the system asks for more proof. This is both more secure and, counterintuitively, often less annoying than the blunt alternative of forcing everyone to re-authenticate on a fixed schedule regardless of risk. Security that calibrates its demands to actual risk spends the user's patience where it buys the most protection. The concentration risk of the identity provider Placing this much weight on identity creates a risk that must be named, because to ignore it would be to repeat, in a new place, the perimeter's error of a single catastrophic point of failure. If identity is the foundation on which all access rests, then the system that governs identity — the identity provider, the directory, the authentication infrastructure — becomes the most valuable target in the entire environment. Compromise it, and an attacker does not merely gain access to one resource; they gain the ability to be anyone, to mint identities and grant themselves entitlements, to authenticate as any user to any system that trusts the provider. The identity provider is the new domain controller, and its compromise is the new game-over. This is not an argument against identity-centric security, because the alternative — scattering trust across the network as the perimeter did — was demonstrably worse. It is an argument for defending the identity infrastructure with proportionate ferocity, treating it as the crown jewel it has become. The disciplines are demanding and specific. The identity provider itself must be protected by the strongest available authentication, so that administrative access to it is the hardest thing in the environment to obtain. The ability to change identity configuration — to create accounts, alter entitlements, modify authentication policy — must be tightly held, closely monitored, and subject to the just-in-time and separation disciplines that privileged access demands, because these are the powers an attacker who reaches the provider will try to use. The provider's own activity must be watched with particular care, because anomalies there are the earliest warning of the most serious possible compromise. And the organization must think hard about resilience: what happens if the identity provider is unavailable, or compromised, and how access decisions degrade or fail when the foundation itself is in question. The broader point is that centralizing trust in identity does not eliminate the single-point-of-failure problem; it relocates it, from the network perimeter to the identity infrastructure, and the relocation is only an improvement if the new single point is defended far better than the old one was. Fortunately, a single, well-defined, intensely monitored identity infrastructure is a far more defensible thing than a sprawling, flat network interior, because it is one thing to watch rather than everything, and because the disciplines for defending it are well understood. But the defense must actually be mounted. An organization that makes identity its perimeter and then protects its identity provider carelessly has simply moved its fatal weakness to a new address and left the door there unlocked. Identity beyond the human A final and increasingly dominant point: most requests in a modern environment are not made by humans at all. They are made by machines — services calling other services, workloads authenticating to databases, automated processes reaching application programming interfaces, scripts and pipelines and functions. These non-human identities now vastly outnumber human ones in many environments, and they are governed far more poorly. The failure mode here is the long-lived secret left lying around. A service needs to authenticate to a database, so a developer gives it a password or an access key, and that credential gets written into a configuration file, a source code repository, an environment variable, a container image. It does not expire. It is shared across systems. It is forgotten. And when an attacker finds it — and attackers scan constantly for exactly these leaked secrets — it grants access that no human is watching and no review ever revisits. Many of the most damaging cloud breaches trace back to a leaked long-lived credential belonging to a machine identity. Zero trust demands that machine identities be governed with the same rigor as human ones, which means giving each workload a strong, verifiable identity; issuing short-lived credentials that expire quickly rather than long-lived secrets that persist; rotating and vaulting secrets rather than scattering them through code; and applying least privilege to workloads just as strictly as to people, so that a compromised service can reach only what it genuinely needs. This is harder than it sounds, because machine identity has historically been an afterthought, but it is not optional. In an environment where machines make most of the requests, an identity strategy that governs only humans has secured the minority and left the majority open. The workload chapters later in this booklet return to this, but the principle belongs here, with identity: in zero trust, everything that makes a request has an identity, and every identity is governed. Identity, then, is the foundation — strong, phishing-resistant authentication so that proof of identity cannot be forged; governance and least privilege so that each identity holds only the access it needs; continuous evaluation so that trust granted can be withdrawn; and discipline extended to machines as rigorously as to people. Get this right and the rest of zero trust has something solid to stand on. Get it wrong and everything built above it inherits the weakness. But identity is not the whole story, because an authenticated identity can be operating from a compromised device, and a device the system cannot vouch for is a signal the policy engine must not ignore. That is where we turn next. Hashtags: #ZeroTrustArchitecture #EnterpriseNetworkSecurity #ZeroTrustSecurity #NeverTrustAlwaysVerify #ContinuousVerification #IdentityCentricSecurity #IdentityAsTheNewPerimeter #LeastPrivilege #Microsegmentation #PolicyDecisionPoint #PolicyEngine #PolicyAdministrator #PolicyEnforcementPoint #DevicePosture #ContextAwareAccess #ContinuousAuthentication #RiskBasedAuthentication #PhishingResistantMFA #PrivilegedAccessManagement #MachineIdentity #WorkloadIdentity #LateralMovement #ZeroTrustNetworkAccess #MultiCloudSecurity #FutureOfZeroTrustSecurity

Download the Book (PDF): Introduction The title is a slogan, and slogans are the enemy of a good paper. Taken at face value — people, not technology, are the real key to digital transformation — it says something everyone agrees with and nobody can act on, and taken literally it is not even defensible, since a firm with no technology transforms nothing. A student who writes three thousand words defending that proposition has defended a platitude, and will be marked accordingly. The book is making a sharper claim than its cover suggests, and stating it precisely is the first thing this companion does. The fallacy is a category error about what kind of thing digital maturity is. A technology is an artefact. It can be specified, procured, installed and signed off; a project delivers it, a milestone closes, and somebody can truthfully say the thing is finished. Digital maturity is not an artefact, and it is not even a state. It is a rate — the speed at which an organisation can keep adapting to conditions that keep changing. Everything follows from that distinction. A rate cannot be purchased, because nobody sells one. It cannot be delivered, because there is nothing to hand over. It has no completion date, because the conditions it responds to do not stop changing. And it does not persist: an organisation that stops doing the things which made it adaptive is not adaptive any more, however mature it was last year. That last property is the one firms find hardest, because an asset acquired stays acquired and a rate does not. Organisations make this error for a structural reason rather than a stupid one. They are extremely good at acquiring things — the business case, the procurement process, the project plan, the capital budget, the milestone report and the benefits review are all instruments for acquisition, and they work. None of them can acquire a rate. So a firm that wants to become adaptive instantiates that ambition as a programme, because a programme is the instrument it has, and a programme is precisely the wrong one: it has a scope, a budget and an end, and an adaptive capacity has none of these. The programme then succeeds on its own terms and fails on the question that prompted it, which is an outcome nearly everyone reading this will recognise. Read through that lens, the research findings stop being a list and become a prediction. If maturity is a rate, then the practices associated with it should be ones that raise the speed of adaptation — cheap experiments, work that crosses functional boundaries, decisions taken without escalation, learning that continues — rather than ones that acquire capability, such as spending more, buying better tools or hiring specialists. That is what Gerald Kane, Anh Nguyen Phillips, Jonathan Copulsky and Garth Andrus report, from a multi-year research programme run jointly by MIT Sloan Management Review and Deloitte. The theoretical framing comes first, and the pattern is what it implies, which is why the framing is worth adopting. There is a second reason this companion exists, and it is the one that matters most for a mark. The book draws on information systems, organisational behaviour, sociology of work and human resource management simultaneously, and papers written about it tend to inherit that breadth as incoherence. The characteristic essay opens at the level of industries and disruption, moves to organisational culture, cites something about individual motivation, concludes that leadership is important, and cannot say what evidence would have obliged a different conclusion. It has changed level of analysis three times without noticing, and each level has different units, different constructs, different data and different standards for what counts as an explanation. So the discipline this companion teaches, alongside the content, is focus: choose a level of analysis and treat the others as context; choose one theoretical tradition and meet its standards; define the construct so precisely that it could fail to apply; and state how it would be measured. The final chapter works through this as a method, with the levels set out explicitly and three worked rewrites turning slogan-shaped theses into claims with a named mechanism and an observable prediction. The third commitment is to treat the evidence seriously, which means neither citing it uncritically nor waving it away. This book's authority rests almost entirely on its research base; it is not a theoretical work and does not pretend to be. So Chapter 2 examines the central measure in detail — respondents are asked to imagine an ideal organisation transformed by digital technologies and to rate their own against it on a ten-point scale, then grouped into early, developing and maturing bands. That is a single-item, self-reported, respondent-anchored measure, and each of those three properties has consequences. The anchoring problem is the deepest and least discussed: because each respondent imagines their own ideal, the scale's zero point moves between respondents, and a person in a more advanced firm has probably seen more of what is possible and therefore holds a more demanding ideal. Chapter 9 extends this to the whole design — cross-sectional data, common method variance, single informants, self-selection — and then makes the balancing point that matters: none of this is unusual, most large-scale management survey research shares it, and a student who treats these as disqualifying has misunderstood the standard. They determine how a claim should be worded, not whether the work is worth reading. That chapter gives the wordings explicitly, because this is where over-claiming costs marks. The chapters run from the argument outward. The first names the fallacy precisely. The second examines the construct on which everything empirical depends. The third treats disruption with the precision the word has lost, replacing it where appropriate with the more useful distinction between change that enhances a firm's existing competence and change that destroys it. The fourth deals with culture as the pattern of behaviour an organisation's incentives actually produce rather than as a values statement, using Schein's levels to make the gap between espoused and observed into an analytical instrument. The fifth handles leadership, including an honest account of why follower-perception measures of leadership correlate with performance partly by construction. The sixth takes talent seriously with self-determination theory, job design and the psychological contract, and insists on separating three problems firms conflate. The seventh covers cross-functional work and its real costs. The eighth deals with organisational learning, which is the tradition the book's continuous-learning material belongs to and rarely names. The ninth is the evidence chapter and the tenth the method chapter. A note on what is not here. No percentages, respondent counts or company outcomes appear anywhere in this book, because none could be verified to a source at the time of writing; the authors' findings are described qualitatively and attributed to them. Every theoretical claim carries an author and a year so that the original can be cited rather than this book being cited for someone else's idea. In a companion whose ninth chapter is about how to evaluate empirical claims, inventing a convincing statistic would be a strange way to proceed. One last observation, offered in the spirit of the book's own argument. The reason its central claim is worth holding onto is that it does not depend on the survey at all. That adaptive capacity is a rate rather than an asset follows from what the two words mean and from how organisations are built, and it would remain true if no firm had ever been surveyed. That is unusual in this genre, and it is why the book has outlasted a great deal of writing published alongside it. Chapter 1: Naming the Fallacy Precisely "People, not technology, are the real key to digital transformation." Put that sentence in front of a room of senior managers and you will not find an opponent. Heads move. Nobody objects. Somebody says that it is exactly what they have been arguing for years. Then the meeting moves on to the platform selection, the vendor shortlist and the implementation timeline, and nothing whatsoever has changed. Universal agreement of that kind is a symptom rather than an achievement. A proposition that no one in the room is willing to contest is usually a proposition that carries no instruction: it tells nobody to stop doing anything, to spend money differently, or to hold a different meeting next Tuesday. It is a sentence that costs nothing to believe. Worse, taken at face value the slogan is not even a defensible claim. Technology plainly matters. A firm with no technology transforms nothing; a retailer whose stock data is three days old cannot make decisions at the speed its competitors make them, however admirable its culture; a bank that cannot expose an interface to a partner cannot participate in the partnerships that are reshaping its market, however empowered its staff feel. The authors of The Technology Fallacy are not confused about this. A multi-year research programme run jointly by MIT Sloan Management Review and Deloitte, combining an annual global survey of managers, executives and analysts with executive interviews, is not a programme conducted by people who believe technology is beside the point. Read the title as a literal proposition and you attribute to four serious researchers a position none of them holds. This matters immediately and practically for anyone writing about the book. A paper that sets out to defend the slogan has set out to defend a platitude, and a platitude cannot be defended because it cannot be attacked. The characteristic result is an essay that assembles supportive material for a claim that no evidence could have contradicted, reaches the conclusion it began with, and receives a mediocre mark for reasons the writer finds mystifying. The problem is not effort or reading. The problem is that the thesis was never a thesis. Something sharper is available, and it is what the book is actually arguing, even where the title obscures it. A rate is not an artefact The fallacy is a category error. It is a mistake not about how much technology matters but about what kind of thing the target of a transformation actually is. Consider what a technology is. It is an artefact. It can be specified in a requirements document, costed, put out to tender, procured, delivered, configured, tested against acceptance criteria, signed off and capitalised on a balance sheet. Somebody owns it. Somebody can stand in front of a steering committee and say that it is finished, and be telling the truth. There is a date on which the enterprise resource planning system went live, a date on which the old platform was decommissioned, a moment at which the project closed and the team was disbanded. Artefacts have edges. That is what makes them manageable, and it is why the entire apparatus of corporate governance is comfortable with them. Now consider digital maturity. It is not an artefact, and here is the step most readers miss: it is not even a state. A state would still be reachable. A state could be achieved, entered, and then maintained with modest effort, the way a building once constructed continues to stand. Digital maturity is a rate. It is the speed at which an organisation can keep adapting as the conditions around it keep changing. Not how well adapted it is, which is a snapshot, but how quickly it can become adapted to something it has not yet encountered. The consequences of that distinction do all of the analytical work in this book, and they are worth stating one at a time because each of them dismantles a familiar corporate practice. A rate cannot be purchased. There is no vendor from whom an organisation can buy the capacity to respond quickly, because what is being bought would have to be the behaviour of thousands of people making decisions the vendor will never see. A rate cannot be delivered, because nothing arrives; there is no crate, no licence key, no go-live weekend. A rate has no completion date, so the question "when will we be digitally mature?" is not a hard question with an uncertain answer but a malformed question, like asking at what point a runner has finished being fast. And most importantly, a rate does not persist without the conditions that produce it. An organisation that stops running experiments, stops forming teams across functional boundaries, stops letting decisions settle where the information is, and stops learning is not an adaptive organisation any more. It does not matter how adaptive it was last year. Last year's rate was a property of last year's conditions, and those conditions were dismantled. The fitness comparison is the obvious one and it is broadly honest: an individual can buy the equipment but cannot buy the cardiovascular capacity, and the capacity decays when the training stops. But the comparison understates the organisational case in one important respect. A person's fitness decays slowly and predictably over weeks. An organisation's adaptive rate can be destroyed in an afternoon by a reorganisation that severs the informal channels through which work actually moved, by a cost programme that eliminates the slack experimentation requires, or by a single public punishment of a team whose sanctioned experiment failed. Rates are fragile in a way that assets are not. Nobody accidentally deletes the warehouse. There is a quiet piece of evidence that the authors understand this, and it sits inside their own measurement instrument. The research programme asks respondents to imagine an ideal organisation transformed by digital technologies and capabilities, and to rate their own organisation against that ideal on a ten-point scale. Respondents are then grouped into three bands: early stage, developing, and maturing. Note the third label. Not "mature", which would name a state that has been reached, but "maturing", a present participle naming something still in motion. The instrument's own vocabulary refuses to describe the destination as arrived at. That choice is not decorative, and later chapters will return to what else this measure does and fails to do, because a single-item, self-reported, respondent-anchored scale carries methodological consequences that any serious paper on this book has to confront. Why capable organisations make the error The error is not a failure of intelligence, and treating it as one produces bad analysis. Executives who make this mistake are frequently the same executives who successfully integrated an acquisition, restructured a supply chain, or navigated a regulatory transition. The explanation has to be structural, and it is. Organisations are extraordinarily good at acquiring things. The entire machinery is built for it. A business case exists to justify expenditure against a defined benefit. A procurement process exists to convert a specification into a contract. A project exists to convert a contract into a delivered thing, within a scope, on a schedule. A capital budget exists to allocate money to assets that can be depreciated. A milestone report exists to demonstrate that the thing is arriving on time. A benefits realisation review exists to confirm, some months after the thing arrived, that it did what the business case said it would. Every one of these instruments is a mechanism for acquisition. Collectively they are one of the more impressive achievements of modern management, and they are the reason large organisations can build refineries and merge balance sheets. None of that machinery can acquire a rate. Not one component of it. There is no line in the capital budget for a shorter feedback loop, no acceptance test for a team that decides without escalating, no benefits realisation review that could confirm the organisation has become faster at responding to things nobody predicted. The predictable result follows without anybody behaving foolishly. A firm decides it wants to become adaptive. That ambition must now be turned into something the organisation can act on, and the organisation's rules of legitimacy are unforgiving: to obtain money you need a business case, a business case requires a defined benefit, a defined benefit requires a scope, and a scope requires an end. So the ambition is instantiated as a digital transformation programme, with a director, a budget, a governance board, a roadmap, and a completion date somewhere around thirty months out. This is not a mistake of judgement. It is the only shape in which the ambition could pass through the organisation's own filters. A programme is the instrument the firm has. And a programme is precisely the wrong instrument, for exactly the reasons already given. It has a scope; an adaptive capacity has no scope, because the point of it is to handle what was not in scope. It has a budget; the thing being built is a pattern of daily behaviour that is not funded from a budget line but from how people spend their ordinary week. It has an end; a rate has no end, and when the programme closes, the conditions it temporarily created, the cross-functional teams, the permission to experiment, the shortened approval chains, are dismantled along with it, because they were project resources and the project is over. This produces the outcome that puzzles everyone involved. The programme can succeed on its own terms and fail on the real question. The systems went in. The milestones were hit. The benefits were signed off. And the organisation is no faster than it was before, because speed was never what was delivered. In the worse cases the programme actively consumed the slack that adaptation requires, since running it absorbed precisely the senior attention, the discretionary time and the tolerance for disruption that experimentation needs. That mismatch between instrument and object, rather than any deficit of will, understanding or commitment, is what the book's title is pointing at. The fallacy is not believing in technology. It is reaching for an acquisition process to obtain something that is not acquirable. The wizard, the curtain and the shape of the argument If maturity is a rate, the practices associated with it are predictable before anyone looks at the data. They should be practices that raise the speed of adaptation: the ability to run cheap experiments and find out quickly which ones fail, the ability to assemble teams across functional boundaries without a reorganisation, the ability to make decisions at the point where the relevant knowledge sits rather than escalating them to a level where the knowledge has been summarised away, and the habit of continuous learning that keeps individual capability moving as fast as the environment. They should not be practices that acquire capability: spending more, buying better tools, hiring specialists. Those raise the stock. They do nothing directly to the rate, and a purchased specialist inserted into an organisation that escalates every decision will simply escalate more expensively. This is exactly the pattern the authors report from their research. The maturing organisations are distinguished by how they work rather than by what they own. The point to hold onto is the order of the reasoning. The prediction comes first. If the finding is encountered as a list of admirable behaviours, it reads as one more set of best practices, and best practices are infinitely extensible and mutually contradictory. If it is encountered as the consequence of a framing, it is doing theoretical work: this is what a rate account of maturity implies, and the data are consistent with the implication. That is the reason to adopt the framing rather than the slogan. It generates predictions the slogan cannot generate, and predictions are what make a paper falsifiable. The intellectual lineage is respectable here too, since the tension the framing describes is recognisably the one James March set out in 1991 between exploration and exploitation, and the capacity being described has a good deal in common with what Wesley Cohen and Daniel Levinthal called absorptive capacity in 1990. The authors reach for the Wizard of Oz to make a related point, and the metaphor deserves better than the dismissal it usually receives. It is worth taking seriously. The great and terrible Oz presents as an overwhelming force, all booming voice and smoke and fire, and the correct response to an overwhelming force is either submission or flight. Behind the curtain there is a man operating a machine. Crucially, the story does not conclude that the threat was imaginary or that nothing was at stake; Dorothy's problems are entirely real and the machine genuinely works. What changes is the category of the thing being faced. It is a mechanism operated by people, and mechanisms can be understood. What this buys analytically is a relocation of the central question. "What will the technology do to the firm?" is unanswerable, because it depends on which technologies emerge, in what sequence, adopted by whom, at what cost, under what regulation. It is also a question that positions the firm as an object to which things happen, and the natural posture it induces is fatalism dressed up as realism, the executive who explains that the sector is being disrupted in the same tone he might use to describe weather. "How does this firm navigate a changing environment?" is answerable. It is a question about the firm's own conduct, over which the firm has authority, and every element of the answer is something someone can decide to do differently on Monday. The metaphor converts a forecasting problem, which cannot be solved, into a capability problem, which can. Nobody can predict which technology will matter. Anybody can ask how quickly their organisation would notice and respond if one did. The book is organised in three parts, and the ordering is not arbitrary. The first part treats the phenomenon of digital disruption itself and how companies should adapt to a changing environment. The second works through what digital maturity implies for leadership, talent and the future of work. The third sets out the conditions organisations need to create in order to adapt successfully. That sequence is diagnosis, implication, prescription: what is happening, what it means for the people inside the firm, and what must therefore be built. The third part carries most of the book's practical weight, since it is where the conditions are named. The second carries most of its academic interest, because that is where the book's constructs run into established literatures on leadership, motivation, job design and the employment relationship, and where its claims are therefore most contestable and most worth a student's attention. The focus problem There is a second reason this companion exists, and it has nothing to do with the book's argument and everything to do with what happens when students write about it. The Technology Fallacy draws simultaneously on information systems, organisational behaviour, sociology and human resource management. For a general management readership this breadth is a virtue; the book covers the territory a practitioner actually inhabits. For a student writing an assessed paper it is a trap, because a paper written about the book tends to inherit the breadth as incoherence. Three failures recur, and they are worth naming in advance so they can be recognised in one's own draft. The first is mixing levels of analysis. An argument begins with an individual's attitude to a new system, moves to how a team coordinates, slides to a firm-level capability, and finishes with a claim about industry structure, with causal arrows running silently between all four. Each of those is a legitimate object of study, and the inferential rules connecting them are not automatic. The second is borrowing constructs from traditions with incompatible standards of evidence. A paper will invoke the technology acceptance model, a variance-based, survey-measured, individual-level tradition following Fred Davis in 1989, in the same paragraph as Edgar Schein's interpretive, organisation-level account of culture from 1985, and treat the two as though they were making commensurable claims about the same world. They are not, and the sentence that joins them is doing no work. The third, which usually follows from the first two, is arriving at a conclusion that nothing in the paper could have falsified. If no imaginable finding would have led to a different last paragraph, the paper has described rather than argued. The discipline the rest of this companion teaches is narrow and can be stated in four moves. Pick a level of analysis and stay on it, or state explicitly how you are crossing between levels and why the crossing is warranted. Pick one theoretical tradition and accept its standards of evidence rather than borrowing whichever construct is locally convenient. Define the construct precisely enough that a reader could disagree with the definition. And say how it would be measured, in terms specific enough that someone could go and do it. The source text makes this unusually practicable, because its own central measure is stated plainly and is therefore available for examination: a single-item, self-reported, respondent-anchored rating against an imagined ideal. Whether such a measure can carry the weight the book places on it is a genuine question, and a genuine question is exactly what a paper needs. The fallacy, then, is not a belief about technology at all. It is the treatment of an ongoing capacity as a one-off acquisition, and it is committed most reliably by organisations that are extremely competent at acquisition. Once that is seen clearly, the recommendations in the book's third part stop looking like a collection of soft cultural preferences and start looking like what they are. Distributed decision rights, cross-functional teams, cheap experimentation, continuous learning: none of these are pleasant working conditions offered to staff as a benefit. Each is a piece of machinery for producing a rate, deliberately constructed because an organisation built for acquisition does not possess such machinery naturally and will not grow it by accident. The book is an argument about how to build an institution capable of changing continuously, addressed to institutions that were designed to change once. Questions for analysis 1. The chapter argues that the slogan "people, not technology, are the key to digital transformation" is indefensible when taken literally, yet the book bearing that title is a serious piece of research. Reconstruct the authors' actual claim in a single sentence that a reader could disagree with, and explain what evidence would count against it. 2. Distinguish an artefact, a state and a rate as candidate answers to the question "what kind of thing is digital maturity?". Which of the three consequences of the rate framing (non-purchasability, absence of a completion date, non-persistence without supporting conditions) does the most damage to conventional transformation governance, and why? 3. The chapter insists that organisations instantiate adaptive ambitions as programmes for structural rather than cognitive reasons. Set out that structural argument in your own terms, then assess it: is there any organisational instrument, existing or imaginable, that could fund and govern a capacity without converting it into an acquisition? 4. The rate framing predicts which practices will be associated with maturity before any data are examined. Explain why the order of that reasoning matters for the strength of an argument, and what is lost when the same findings are presented as a list of best practices instead. 5. Identify a claim from the book that operates at the individual level and one that operates at the organisational level. What would have to be true for the first to license the second, and how would you state a research design that tested the connection rather than assuming it? Chapter 2: Digital Maturity as a Construct The question that produces the book's central variable is worth quoting in substance, because almost everything that follows depends on it. Respondents are asked to imagine an ideal organisation transformed by digital technologies and capabilities, and then to rate their own organisation against that imagined ideal on a ten-point scale. Those who place their organisation low on the scale are classed as early stage; those in the middle band as developing; those at the top as maturing. Every comparison in the MIT Sloan Management Review and Deloitte research programme - between cultures, between leadership qualities, between talent outcomes, between attitudes to experimentation - is a comparison between those three groups. The entire empirical structure rests on one question and the three buckets its answers are sorted into. This is a single-item, self-reported, respondent-anchored measure. Each of those three properties is a design decision, each carries a cost, and the costs are not the same kind of thing. Single-item measurement is a reliability question with a large and mostly reassuring methodological literature behind it. Self-report is a bias question with well-catalogued mechanisms and well-known remedies. Respondent anchoring is something stranger: a property that makes the scale itself vary between the people using it, and one that the standard methods literature does not have a clean solution for. A student who can distinguish these three problems from one another, and say which is serious for which kind of claim, is already doing better methodological work than most of what is written about this research. There are two failure modes to avoid, and they are mirror images. The first is to cite the findings as though the bands were an objective classification - to write that maturing organisations retain talent better, full stop, as if maturity were a measured property like headcount or revenue. The second is to notice the word "self-reported" and dismiss the whole programme as opinion polling. Both are lazy. The measure is not an objective classification, and it is also not noise. It is a particular kind of evidence, with a particular reach, and the productive task is to work out exactly how far that reach extends. That is not a concession made reluctantly at the end of a paper. It is the analytical work itself, and in an assessed piece it is where the marks are. It helps to be clear about what the measure is for. The authors are not certifying organisations; they are sorting a large and varied global sample into rough strata so that the strata can be compared on everything else the survey reports. For that purpose a coarse instrument may be adequate. Whether it is adequate depends on what the construct underneath it is like - and, as the rest of this chapter argues, the construct is unusually awkward, because the book defines digital maturity as an ongoing process of adaptation while the survey measures it as a position at a moment. One item, and what it is being asked to carry The objection to single-item measures is procedural and real. With one item there is no internal consistency to assess: no Cronbach's alpha, no inter-item correlations, no way of showing that several indicators converge on a common underlying factor. The apparatus that Campbell and Fiske set out in 1959 for demonstrating convergent and discriminant validity - showing that a measure agrees with other measures of the same thing and diverges from measures of different things - has nothing to work with inside the instrument. Measurement error cannot be partitioned out, so it stays in the estimate and attenuates observed relationships. And a single item cannot capture a multidimensional construct: if digital maturity has separable components, one number flattens them into an average that may describe no actual organisation. The defence is also real, and a paper that omits it is not being rigorous, only sceptical. A substantial body of measurement research finds that for global, holistic judgements, a single well-worded item performs comparably to a multi-item scale. Overall job satisfaction is the classic case; global self-rated health is another. The logic is that when the thing being assessed is genuinely a summary judgement - the respondent's overall sense of a whole - asking for that summary directly is not a degraded version of asking twenty questions and averaging. It may be a more direct route to the same quantity. And there is a practical argument that carries real weight in survey design: every additional item costs respondent attention, and in a long instrument administered annually to busy managers across many countries, spending fifteen items on the classification variable means fifteen fewer items on everything the classification is meant to explain. Instrument length degrades data quality through fatigue and satisficing. A single item buys accuracy elsewhere. So the honest position is conditional. A single item is a defensible choice for a broad construct and a poor one for a precise construct. If digital maturity is a gestalt - the respondent's overall impression of how far their organisation has travelled - then one item is a reasonable instrument and the objection is largely procedural. If digital maturity is a compound of distinguishable capabilities that can move independently, such that a firm might be advanced in decision rights and primitive in data infrastructure, then one number conceals exactly the variation that matters, and two firms with identical scores may have nothing in common. Which of these digital maturity is turns out to be the substantive question of the book, not a technical aside. The book's own argument leans towards the gestalt reading: it insists that maturity is not a stack of capabilities but a way of operating, an organisation-wide rate of adaptation that shows up across functions at once. If that is right, a holistic self-assessment is a defensible probe of it. But the same argument cuts the other way when the findings are used, because a gestalt measure cannot then be read back as though it decomposed into the specific practices the book recommends. You cannot measure the whole and then report on the parts. The moving anchor The deepest problem with the measure is the one almost never raised, and it follows directly from the wording. The respondent is not rated against a fixed standard. They are asked to construct the standard themselves - to imagine an ideal digitally transformed organisation - and then to say how far their own organisation falls short of the thing they have just imagined. The anchor is supplied by the respondent, and it varies between respondents. Consider two firms that are, by any external description, identical: same sector, same systems, same decision structures, same analytical capability. In one, the respondent's mental picture of an ideal digital organisation is drawn from a mid-market competitor that has recently automated its order processing. In the other, the respondent has spent time inside a firm where product teams ship continuously and pricing adjusts in real time, and that is the picture they hold. The first respondent rates their organisation high. The second rates the identical organisation low. The difference in scores records nothing about the firms and everything about the two imaginations. Worse, the variation is unlikely to be random. A respondent's ideal is probably more ambitious in an organisation that is already more advanced, precisely because working in such a place exposes you to more of what is possible. Sophistication raises aspiration. If that holds, the anchor drifts upward with the very thing the scale is trying to measure, and the two movements partly cancel: advanced firms are rated against sterner ideals, early-stage firms against modest ones, and the observed spread between them is narrower than the real spread. In the limit, if aspiration rises faster than capability, the correlation could invert, and the most advanced organisations could report themselves furthest from their ideal. Nothing in the design rules this out. That possibility has an interesting implication. If the anchor moves with the respondent, then what the item measures may not be a position on any common scale at all. It may be the gap between an organisation and its own aspiration - a measure of felt shortfall rather than of achieved capability. That is not a worthless quantity; it may well be a good predictor of restlessness, of appetite for change, of the sense that there is further to go. But it is a different construct from the one the bands are named after, and findings interpreted under the two readings mean different things. Under the standard reading, maturing organisations have better cultures. Under the gap reading, organisations whose members feel close to their own ideal also describe their cultures favourably - which is a considerably less surprising claim. This problem has no clean fix inside the existing design. Objective anchors would require external benchmarking the survey does not do. Vignette anchoring, in which respondents first rate fixed hypothetical cases to calibrate their scale use, would help and is not part of the instrument. Stating the problem plainly, and saying which of the two readings a particular finding can bear, is the available move - and it is exactly the kind of methodological awareness that separates a strong paper from a competent one. Examiners notice a student who can identify an unresolved problem in a published research design and reason about its likely direction, rather than reciting a list of generic limitations. The same voice on both sides The maturity score and most of the outcomes come from the same person, answering the same instrument, in the same sitting. The respondent who places their organisation at eight out of ten also tells the survey that its culture is collaborative, that its leaders are digitally fluent, that it attracts and keeps good people, and that it performs well. Podsakoff and colleagues set out the consequences of this arrangement comprehensively in 2003: when predictor and criterion share a method, some portion of the observed relationship between them is produced by the method rather than by the world. The mechanisms are worth naming in plain language, because "common method variance" as a phrase is often deployed without content. Consistency motifs: people want their answers to hang together, and having just described their organisation as advanced, they are under mild pressure to describe it as well-led. Implicit theories: respondents carry lay causal beliefs, and someone who believes that adaptive firms have strong cultures will report both in line with that belief, generating a correlation that exists in their head before it exists in their firm. General affect: someone who feels positively about their employer, for reasons that may have nothing to do with digital anything, rates every item on the instrument a little higher, manufacturing correlations across the whole battery. Add scale-format effects and the priming produced by item order, and the inflation is not a marginal concern. The standard remedies are well established. Temporal separation - measuring predictor and outcome weeks or months apart - breaks the consistency motif and the momentary affect. Different sources - maturity from the executive, retention from HR records, performance from financial statements - break the shared-respondent link entirely and are the strongest remedy available. Procedural protections such as guaranteed anonymity and counterbalanced item order reduce, without eliminating, the pressure to look consistent. Statistical diagnostics, including marker variables, attempt to estimate how much is left. The honest account of this design is that it uses some of these and not the most powerful ones. Anonymity is present and matters. The survey draws on multiple respondent types across many organisations, so the sample is not a single homogeneous group. Executive interviews run alongside the survey and give a second kind of evidence, though a qualitative and non-independent one. What the design does not do is separate predictor and outcome in time or in source, and it does not report marker-variable diagnostics. That does not mean the associations are fictitious. It means their magnitude is an upper bound, and any reported difference between bands should be read as the largest the true difference could plausibly be. Two further features of the sample cut in the same direction and deserve evenhanded treatment. Respondents to a voluntary survey about digital business are not a random draw from the world's managers. They are people interested enough in the subject to answer a long questionnaire about it, which tilts the sample towards the engaged, the technically literate, and organisations where the topic is live. And they are describing organisations they belong to, whose digital efforts they may personally have led. Both pressures point the same way: towards flattering descriptions, both of the organisation's progress and of the conditions around it. Social desirability here is not mainly about deceiving the researcher; it is about how people describe work they are part of and invested in. None of this invalidates the research, and a paper that concludes otherwise has misunderstood the design. The comparisons of interest are internal - between groups within the same sample, answering the same instrument under the same pressures. If every respondent inflates, and inflation is roughly constant across bands, differences between bands survive. The risk is specifically that inflation is not constant, which brings the anchoring problem back: the respondents most likely to hold demanding ideals are also, plausibly, those least likely to flatter. What the measure will bear The practical payoff is a clear statement of reach. This measure supports claims of the form: organisations whose respondents describe them as more adapted to a digital environment also describe, on the same instrument, different cultures, different leadership, different talent outcomes and different attitudes to risk than organisations whose respondents do not. That is a real finding about a large and varied sample, and it is not trivial - the pattern is consistent, it recurs across years of the survey, and it holds across sectors and geographies. It does not support three things students routinely claim from it. It does not support the claim that maturity causes performance, since the data are cross-sectional and the causal arrow could as easily run from a healthy culture to a confident self-assessment, or from profitability to both. It does not support claims about movement, since a firm that appears in a later survey in a higher band may have changed, or may have a different respondent with a different imagination. And it does not support the claim that the bands correspond to any externally verifiable state; no auditor could confirm that a given firm is "maturing", because the category exists only relative to a private standard. Table 1 sets out each property of the measure against the reason for it, what it does to inference, and the form of words a careful paper should use. Table 1. Properties of the digital maturity measure and their consequences. Property of the measure Why it was chosen Consequence for inference What a careful paper should say Single item Low respondent burden; suits a holistic judgement No internal-consistency check; dimensions hidden Treat as a global impression, not a capability audit Self-reported No external data on most firms; scale of sample Desirability and affect inflate levels Read levels as perceptions; compare, do not certify Respondent-anchored ideal Allows one item to span sectors and sizes Anchor varies and may rise with capability Differences may be compressed; possibly a gap measure Cross-sectional Annual survey design; broad coverage No direction of causation; no within-firm change Report association, never effect Same respondent for outcomes Single instrument, single sitting Common method variance inflates correlations Treat differences as an upper bound Voluntary sample Practical recruitment for a global survey Engaged, topic-interested respondents over-represented Restrict claims to within-sample comparisons These limits are not fatal, and they are not a reason to avoid the material. They determine wording, and wording is where students over-claim. Compare two sentences. "Digital maturity improves employee retention" is unsupportable: it asserts causation, treats maturity as a measured property, and generalises beyond the sample. "In the MIT Sloan Management Review and Deloitte survey, respondents who placed their organisations closer to their imagined digital ideal also reported a stronger intention to stay with their employers; because both measures come from the same respondent at the same moment, the association cannot establish direction and its size is likely inflated by common method variance" is fully supportable, and is not much longer. The second sentence also does more work: it tells the reader what kind of evidence is on the table, which is the beginning of an argument rather than the end of one. Maturity models as a genre invite a further round of criticism, most of it deserved. Their stages are typically asserted rather than derived - named from consulting experience and then applied, rather than recovered from data. They imply a single developmental path, as though every organisation must pass through the same sequence towards the same endpoint, which fits neither the variety of industries nor the evidence that firms take different routes. And they ask organisations to assess themselves against the model's own categories, so the model tends to confirm its own structure: a firm told that maturity means cross-functional teams will report on cross-functional teams. This particular construct escapes part of the charge, and the escape is worth crediting because it is unusual in the literature. Because the authors frame digital maturity as an ongoing process of adaptation rather than as an achieved end state, the model does not carry the usual implication that maturity is a destination with a finishing line. "Maturing" is deliberately a participle. Most models in this field promise arrival; this one explicitly denies that arrival is available, which is both more honest and more consistent with what organisations actually experience. That denial, though, is exactly where the sharpest criticism of the research becomes available - and it is a criticism a good paper can build on rather than merely assert. If maturity is a rate, an ongoing capacity to keep adapting as conditions keep changing, then a rate is what should be measured. A single question answered at one moment cannot capture a rate; it captures a level, or more precisely a perceived distance from an imagined point. Measuring a speed from one snapshot is not a technical oversight that better survey administration would fix. It is a real difficulty, and no available instrument solves it cleanly. The conceptual claim and the empirical practice pull against each other, and everything the research reports about maturing organisations is therefore a description of firms that feel far along, offered as evidence about firms that move fast. Those may well be the same firms. The design cannot show that they are - which is precisely the space in which a student with a longitudinal design, an external anchor, or a second data source has something new to contribute. Questions for analysis 1. Under what conditions is a single-item measure defensible, and does digital maturity as the authors define it meet those conditions? Argue the case both ways before deciding. 2. If respondents in more advanced organisations hold more demanding ideals, what happens to the observed differences between the three maturity bands? Work through the likely direction and magnitude of the distortion. 3. The chapter suggests the item may measure the gap between an organisation and its own aspiration rather than its position on a common scale. Take one reported finding from the research programme and restate it under each reading. How do the two versions differ in what they would license a manager to do? 4. Which of the three common method variance mechanisms - consistency motifs, implicit theories, general affect - is most likely to be operating in this survey, and why? What evidence would distinguish between them? 5. Design a study that tests one of the book's central associations while breaking the shared-respondent link. Specify your predictor source, your outcome source, and the temporal separation, and state honestly what your design would still be unable to show. 6. The construct is framed as an ongoing process rather than an end state, but is measured at a single point in time. Is this an inconsistency that undermines the research programme, or an unavoidable compromise? Defend your answer with reference to what a rate would require to measure. Chapter 3: Disruption, Carefully Somewhere between 1997 and the present, disruption stopped being a hypothesis and became a mood. It is now applied to a competitor cutting prices, a regulator changing a rule, a new sales channel, a shift in generational taste, a supply shock, and to any development at all that makes an established firm's year harder than it expected. A word that covers every one of those covers nothing. It has no content left to test, no prediction attached to it, and no way of being wrong — which is exactly the property that makes a term useless in an assessed piece of analysis, however well it performs in a boardroom. This matters for a companion to a book with digital disruption among its core concepts. The source text uses the phrase in its broad, popular sense: the arrival of a new competitive environment shaped by digital technologies, and the question of how organisations navigate it. That is a legitimate thing to write about. But a student who carries the popular sense of the word into a paper marked by someone who knows the strategy literature will be read as making a claim about mechanism, and will then be asked to support a claim they never intended to make. The required discipline is therefore small and entirely practical: know which version of the word you are using, and say so. The mechanism, and the things mistaken for it Clayton Christensen's argument in The Innovator's Dilemma (1997) is not a general observation that incumbents sometimes lose. It is a specific mechanism with specific moving parts, and the parts are what make it interesting. An entrant begins by serving a segment the incumbent does not want — smaller, less profitable, less demanding on the performance dimensions the incumbent's main customers care about. The incumbent notices, evaluates, and declines, and the evaluation is correct. Its best customers want more of what they already buy, its margins are higher in the segments it already serves, and its resource allocation process directs investment towards the highest-return opportunities available to it. Every step of this is competent management. Meanwhile the entrant improves along its own trajectory, and because technological improvement in a given product line tends to run faster than the rate at which mainstream customers' requirements rise, the entrant's performance eventually crosses the threshold that mainstream customers need. At that point the incumbent's customers begin to defect, and the incumbent cannot simply follow them down, because its cost structure, its channels, its margin expectations and its organisational attention are all built around the segment it is losing. The crucial feature — the one that gets dropped every time the word is used loosely — is that the incumbent's failure follows from good management rather than bad. That is why Christensen called it a dilemma rather than a cautionary tale. If the incumbent had been lazy, complacent or badly run, there would be no puzzle and no theory; there would only be the ordinary observation that badly run firms do worse than well run ones. The whole argument rests on the claim that doing the textbook thing — listening to your best customers, investing where returns are highest, protecting your margins — produces the failure. The disk-drive evidence that anchors the book was chosen precisely because product generations there turned over fast enough to observe the cycle repeat. This gives the term diagnostic value, which is what an analytical term is for. Three questions test whether an event is disruption in this sense. Was the entrant initially worse on the dimensions mainstream customers valued? Did the incumbent see it and decline to pursue it for reasons that were defensible given its existing business? Did the entrant's improvement trajectory subsequently overtake mainstream requirements rather than the entrant simply winning on the original terms? Most events described as disruption fail at least one of these tests, usually the first. An entrant that arrives better, cheaper and immediately preferred by mainstream customers is not disrupting anyone; it is competing, and winning. An incumbent that saw a threat clearly, understood it, and failed to respond because its leadership would not authorise the investment is not the subject of Christensen's theory either; it is the subject of a much older and less interesting one about organisational inertia. Neither case is less important than disruption. They simply have different causes, different evidence and different remedies, and collapsing them into one word destroys the distinctions that make analysis possible. The practical instruction for a student is therefore blunt. Either use the term precisely, and show the mechanism operating in your case, or use a different term. Entry, substitution, displacement, commoditisation, disintermediation and environmental change are all available, all narrower, and all easier to defend. Reaching for the more dramatic word costs marks rather than earning them, because the examiner will read it as a claim and find it unsupported. Competence-enhancing and competence-destroying change For what the source text actually describes, there is a better frame, and it is the single most useful analytical instrument available for the job. Michael Tushman and Philip Anderson, writing on technological discontinuities and organisational environments (1986), describe technological change as proceeding through long periods of incremental improvement punctuated by discontinuities — sharp breaks that reset the terms on which firms compete. The valuable part of their argument is not the punctuation. It is the distinction they draw between two kinds of break, which turns on the relationship between the new technology and the accumulated capability of established firms. A competence-enhancing discontinuity raises performance while leaving the existing firms' accumulated capability intact and still valuable. The new thing builds on what incumbents already know how to do, so incumbents tend to be strengthened by it, and industry leaders tend to remain leaders. A competence-destroying discontinuity renders that accumulated capability worthless. The knowledge, the tooling, the supplier relationships, the training systems and the hard-won expertise of the established firms stop being assets and become, at best, irrelevant. Incumbents then fail not because they were slow, not because they failed to notice, and not because they were badly led, but because what they were good at stopped mattering. Speed of response is beside the point when the thing you would be responding with has lost its value. The reason this frame beats the disruption frame for most student work is that it asks a question you can actually answer with evidence. Name the firm's core competence — specifically, not as a slogan. Ask whether the new technology raises or nullifies the value of that competence. You can support the answer with descriptions of what the capability consists of, who holds it, how long it took to build and what it is used for. Whereas "was this disruption?" usually degenerates into an argument about whether the incumbent lost badly enough to qualify. Apply the distinction to the digital case and an honest complication appears immediately. Most digital change, in most industries, has been competence-enhancing for firms that adapted. A retailer's knowledge of buying, category management, credit, logistics and property did not become worthless when selling moved partly online; it became more valuable, because the new channel needed all of it and the firms that already had it were better placed than the entrants who did not. The same is true across banking, industrial manufacturing, insurance, healthcare provision and professional services. The technology changed how the capability was deployed without destroying the capability itself. Where digital change has been genuinely competence-destroying, it has typically destroyed competence at the level of a function rather than a firm — a display advertising sales operation, a branch counter network, a physical distribution intermediary, a typesetting department, a class of clerical processing work. Those destructions are real and severe for the people in them. But they sit inside firms whose other capabilities remained intact, which is precisely why so many whole-industry disruption narratives overstate. The unit of analysis for competence destruction is usually the function or the occupation; the unit of analysis in the narrative is the industry; and the mismatch is where the exaggeration enters. A student can put this to work directly. "Digital technology disrupted industry X" is a claim most undergraduates cannot support and should not attempt. "Digital technology destroyed the value of competence Y within firms in industry X, while leaving competences Z and W enhanced" is a claim that can be evidenced, and it is more interesting besides. It also explains something the source text cares about a great deal. When competence destruction is functional rather than firm-wide, the people whose expertise is being written off are inside the organisation, are frequently senior, and are frequently the ones asked to authorise the change. Their resistance is not ignorance or fear of technology. It is a rational response to a correct perception of what the change does to the value of what they know. Two rates, not one The pace argument in the source text is easy to misread as the usual assertion that everything is faster now, and it deserves better treatment than that, because the authors' actual position is sharper and considerably more defensible. The claim is not that technology changes faster than ever in some absolute sense. That claim is hard to operationalise — faster by what measure, against what baseline? — and has been made with equal conviction in every industrial generation since the railway. The claim is about a gap: the rate at which technology changes has pulled away from the rate at which organisations can absorb it. The environment may or may not be accelerating in absolute terms; what matters is that it is moving faster than the institutions inside it can reconfigure themselves. Three things make this the better framing. First, it locates the problem in a relationship rather than in technology alone. A gap is a ratio between two quantities, and both quantities can be investigated. "Everything is faster now" is an atmosphere; "adoption outpaces absorption in this firm, by this much, for these reasons" is a research question. Second, it is consistent with evidence that the simpler story cannot accommodate. Erik Brynjolfsson's account of the productivity paradox (1993) confronted the awkward fact that very large investments in information technology had produced strikingly little in the way of measured productivity gain. If technology did the work on its own, the effect would be prompt: install, measure, observe. The long lag between investment and return is not a measurement curiosity to be explained away. It is direct evidence that something between the technology and the outcome takes years, and that something is organisational absorption. Third, and most usefully, it relocates the actionable variable. No firm can slow the environment. Every firm can, in principle, change its own absorption rate. A theory that puts all the causal weight on external speed leaves managers with nothing to do but brace; a theory about the gap points straight at the side of it they control. Why is absorption so slow? Paul Milgrom and John Roberts, writing on complementarities, supply the mechanism. Two elements of a system are complementary when doing more of one raises the return to doing more of the other. Technology in organisations is almost never a standalone element; its return depends on complementary changes in process design, decision rights, job design, skills, measurement and incentive structures. Adopt the technology alone and you have paid its full cost and collected a fraction of its value — and performance can genuinely fall, because the new tool sits badly against the old process and the old process still governs. Getting the return requires moving a whole configuration of mutually reinforcing practices from one arrangement to another, and configurations cannot be moved one element at a time without passing through a trough where the old fit has been broken and the new one has not yet been made. That trough takes years, and the years are not waste. They are the work. Absorptive capacity and the things that must stop Wesley Cohen and Daniel Levinthal's account of absorptive capacity (1990) is the formal treatment of why some organisations absorb faster than others. They define the capacity as the ability to recognise the value of new external information, assimilate it, and apply it to commercial ends — and they argue it is largely a function of prior related knowledge. You understand what you already have the equipment to understand. The consequence is that absorptive capacity is cumulative and path dependent. It is built by having been engaged with a domain, and it cannot be assembled on demand. A firm that has not been absorbing cannot suddenly start, because the first step — recognising which of the many developments in front of it actually matter — requires exactly the knowledge that only prior absorption produces. Such a firm does not fail to act on the signal; it fails to see that there is a signal. It learns which developments mattered at the point where they have become obvious to everyone, which is the point at which knowing is worth nothing. The uncomfortable implication should be stated plainly, because it cuts against most of what is written about adaptation. The firms best placed to adapt are the ones that have already been adapting. This is a mechanism for divergence, not convergence. It predicts that the distance between adaptive and non-adaptive firms widens over time rather than closing, and that the widening accelerates, since each period of absorption raises the capacity to absorb in the next. It also predicts that the standard remedy — a large one-off investment by a firm that has done little — will underperform, because the money buys the technology and not the recognition. This is a genuinely testable proposition, and it is a far more precise version of what the source text's maturity bands gesture at than the bands themselves provide. What, then, does adaptation actually consist of, stated as capacities rather than as encouragement? Four things, each of which can be absent independently. Scanning the environment, which requires somebody whose job it is to look, with time protected from operational load — scanning that belongs to everybody belongs to nobody and does not happen. Deciding, which requires that authority to act sits at the level where the signal was seen, since a signal that must climb three levels to reach someone empowered to respond arrives degraded, attributed to the wrong person, and late. Reallocating, which means moving money, people and attention out of current uses and into new ones. And absorbing, which means having the capability to use what has been adopted, procurement being the beginning of absorption rather than a substitute for it. Most organisations are weakest at the third, and this is the specific bottleneck that most limits adaptive rate. Starting things is politically cheap: a new initiative creates a sponsor, a budget line and a story. Stopping things is politically expensive, because every existing activity has an owner, a headcount, a history, an internal constituency and often a customer who likes it. Budget processes are incremental and start from last year. Initiatives are launched with objectives but almost never with termination criteria, so nothing ever fails clearly enough to be killed. The result is accumulation, and accumulation is not neutral. Everything that continues consumes the capacity that adaptation requires — not chiefly money, but management attention and the time of the people capable of doing new work, who are invariably the same people already doing the existing work. A firm's adaptive rate is therefore set, more than by anything else, by its rate of stopping. A firm that cannot stop things has a ceiling on what it can absorb no matter what it spends. This is where the source text's Wizard of Oz metaphor earns its place, and it is worth taking seriously rather than treating as decoration. A narrative in which technology is an overwhelming external force arriving to reshape an industry removes agency from the firms in that industry — and, with the agency, the accountability of the people managing them. That is an extremely convenient piece of storytelling. "The environment did it" is the most comfortable explanation available to anyone who allocated resources badly for a decade, and it has the additional advantage of being unfalsifiable, since the environment did in fact change. Treating the environment as something to be navigated rather than something that happens to you is both more accurate and more useful, and it carries a direct analytical consequence: the interesting variance is between firms in the same environment, not between environments. If technology were doing the causal work, firms facing the same technology would show similar outcomes. They visibly do not. Whatever explains the difference is therefore inside the firm, which is also the correct design for a study — hold the environment constant, compare the organisations. Which brings the argument back to where the book's real claim lives. If the problem is a gap between two rates, the environment's and the organisation's, then the only side of that gap a firm can act on is its own. And a rate is not a thing that can be bought. The technology on the far side of the gap can be acquired in an afternoon, by anyone, at a published price, which is precisely why acquiring it confers no advantage. The gap is on your side of the transaction, and nothing in the catalogue closes it. Questions for analysis 1. Take an industry change commonly described as digital disruption and test it against the three diagnostic questions drawn from Christensen's mechanism: was the entrant initially inferior on the dimensions mainstream customers valued, did the incumbent decline it for defensible reasons, and did the entrant's trajectory subsequently overtake mainstream requirements? On the evidence available to you, does the case qualify, and if not, which term describes it more accurately? 2. Using Tushman and Anderson's distinction, identify one specific competence within an organisation you can research, and argue whether digital change has been competence-enhancing or competence-destroying for it. Explain why the answer might differ at the level of the function and at the level of the firm, and what this implies about industry-level disruption claims. 3. The chapter argues that the gap between the rate of technological change and the rate of organisational absorption is a better framing than absolute acceleration. Construct the case against this framing: what evidence would show that absolute speed, rather than the gap, is the operative variable, and how would you distinguish the two empirically? 4. Cohen and Levinthal's account of absorptive capacity predicts divergence between adaptive and non-adaptive firms rather than convergence. What observations would be inconsistent with that prediction, and what does the prediction imply about the likely returns to a large one-off technology investment by a firm with little prior absorption? 5. Of the four capacities described — scanning, deciding, reallocating and absorbing — the chapter claims reallocation is the binding constraint because organisations are poor at stopping things. Evaluate that claim: what would count as evidence that stopping, rather than seeing or deciding, is the true bottleneck in a particular organisation, and how could it be measured? Hashtags: #TheHumanAlgorithm #TheTechnologyFallacy #DigitalTransformation #DigitalMaturity #AdaptiveCapacity #OrganizationalAdaptation #ContinuousLearning #DigitalDisruption #AbsorptiveCapacity #ExplorationAndExploitation #CrossFunctionalTeams #DistributedDecisionRights #CheapExperimentation #OrganizationalLearning #CompetenceEnhancingChange #CompetenceDestroyingChange #OrganizationalAbsorption #TechnologyAdoption #Complementarities #DigitalCulture #DigitalLeadership #TalentAndWorkDesign #OrganizationalAgility #ContinuousAdaptation #FutureOfDigitalMaturity

Download the Book (PDF): Introduction There is a particular kind of confusion that sets in about three weeks into a strategic information systems module. The reading has been done. The textbook has been opened, and it turns out to contain a great many matrices, a great many acronyms, and case studies about companies that were in trouble at various points over the last forty years. Somewhere in the middle of all of it there is a triangle with three words at its corners, and the lecturer has said several times that it is the most important thing in the course. And the honest question forming in the back of the room is: important how? It is three words and three lines. What exactly is it supposed to do? That question deserves a better answer than most courses give it, and answering it properly is what this book is for. The Information Systems Strategy Triangle is a claim, not a picture. The claim is that an organisation's business strategy, its organisational strategy and its information systems strategy are not three separate plans that happen to be written by the same company. They are a single interdependent system. Move one and the other two must move in compensation, or the organisation goes out of balance — and the symptoms of that imbalance will show up somewhere else entirely, usually in a place that looks like a technology problem and is not one. A system that nobody uses. A strategy that was announced and then quietly stopped being mentioned. A market the company could not enter because its core platform was thirty years old and nobody said so out loud. Taught that way, the triangle stops being a diagram to memorise and becomes an instrument. It is a device for converting a vague complaint — our IT is failing us, the transformation isn't landing, the new system was a disaster — into a specific, answerable question about which vertex moved and which one did not follow. That conversion is the whole trick, and it is worth more in an examination, and considerably more in a career, than the ability to reproduce the drawing. The textbook this guide accompanies, Managing and Using Information Systems: A Strategic Approach, has been the standard text on this subject through many editions for good reason. Keri Pearlson, Carol Saunders and Dennis Galletta built it around the triangle and then ran the consequences of that choice through every topic a general manager encounters: strategy, the design of work, architecture, funding, governance, sourcing, projects, security, analytics and ethics. The book is thorough, and its thoroughness is precisely the problem for a student working to a deadline. The controlling idea is stated clearly in the first chapter and then has to survive twelve more chapters of detail, dozens of cases, and a vocabulary of several hundred terms. What tends to happen is that students learn the parts and lose the argument. They can list the five forces and define total cost of ownership and name three sourcing models, and then, faced with a case study and a two-hour exam, they produce a description of the company rather than an analysis of it. This guide is organised the other way round. Every chapter here exists to serve one controlling idea, and that idea is the triangle read as a diagnostic instrument. The first chapter establishes the claim and the three ways a triangle goes out of balance. The next three take each vertex in turn and give it the treatment it needs: what a business strategy actually is and how to read one from a case; what organisational strategy means and why it is the vertex students consistently under-weight; and what an information systems strategy contains, as distinct from a list of technologies somebody would like to buy. Chapter five takes on the question the whole subject circles — whether information technology can create competitive advantage at all, and for how long — and gives Nicholas Carr's famous argument that it cannot a fair hearing before answering it. The second half moves from the analytical to the managerial. Chapter six follows the translation chain from strategy through architecture to infrastructure, and shows how legacy systems run constraints back up that chain to limit which strategies are even available. Chapter seven treats the IS organisation as a business that has to be funded, budgeted and justified, and takes seriously the question of why IT value is so notoriously hard to measure. Chapter eight is about governance, which is to say about decision rights: who gets to decide what, who is consulted, and who carries the accountability when it goes wrong. Chapter nine covers the two decisions that consume most of a chief information officer's working life — where capability is bought from, and how change is actually delivered — and examines why information systems projects fail at rates that would end careers in any other engineering discipline. Chapter ten is the one to read twice. It converts everything preceding it into a repeatable procedure: an ordered method for analysing any case, demonstrated end to end on a worked example, followed by the architecture of a strong essay and, importantly, the serious intellectual criticisms of the alignment model itself. That last section matters more than it might appear. The difference between a competent answer and an excellent one, in this subject, is almost never the amount of material recalled. It is whether the student can use a framework and simultaneously see its limits — whether they notice that the triangle assumes a stable and knowable business strategy, that in a digital-native firm the vertices may not be separable at all because the product is the information system, and that a perfectly aligned organisation may simply be perfectly aligned to a strategy that is dying. A word on how to use this book. It is not a substitute for the textbook and does not pretend to be one; it is a companion that supplies the structure the textbook assumes you will build for yourself. Read it straight through once, early, so that the shape of the subject is clear before the detail arrives. Then return to individual chapters as the module reaches them. Each chapter ends with a section on what examiners actually reward in that area, including specimen questions written out in full, and those sections are worth working through with a pen rather than skimming. The six tables scattered through the book are compression devices for material that is genuinely comparative — generic strategies, funding models, governance archetypes, sourcing options — and they are there to be reproduced from memory as revision aids. Throughout, the examples are real and named. Zara, Ryanair, Walmart, Lidl, Blockbuster, Kodak, Amazon, the UK's National Programme for IT: these are the cases that recur in examination papers and in seminar discussion, and it is more useful to know four of them properly than twenty of them vaguely. Where a fictional organisation appears, in the worked case in the final chapter, it is labelled as such, because the habit of inventing convenient evidence is exactly the habit this subject should train out of you. One last framing, which is the reason this material is worth the effort beyond the assessment. Almost everyone reading this will, within a decade, sit in a meeting where a substantial sum of money is about to be committed to a system, and where the discussion is being conducted entirely in the vocabulary of the technology. The question that will not have been asked is what has to change about the way people work for the investment to produce anything, and who is accountable for making that change happen. Knowing to ask it is what this subject is actually teaching. The triangle is just the shortest way of remembering to. Chapter 1. The Triangle as an Instrument A student meets the Information Systems Strategy Triangle for the first time as a drawing: three words at three corners, three lines between them. It takes about four seconds to copy into a notebook and roughly the same to forget. That is the wrong encounter. The triangle is not a picture of anything; it is a claim about how organisations fail, and it is precise enough to be tested against evidence. Learn it as a claim and it becomes an instrument you can pick up in an exam hall, in a case study, or in the third week of a graduate job when somebody senior says the new system "isn't delivering" and nobody can say why. Three vertices and a single claim The three vertices are business strategy, organisational strategy and information systems strategy. Each deserves a chapter of its own, and each gets one later in this book. What matters at this stage is only what each vertex covers, at the level of a definition you could give in a sentence. Business strategy is the set of choices that determine where an organisation competes and on what basis it expects to win. It answers the questions of which customers, which markets, which products and services, and what it is about the offer that makes a customer choose it rather than the obvious alternative. A business strategy is meaningful only to the extent that it excludes things: a strategy that permits every possible action is a mission statement wearing a disguise. Ryanair's strategy excludes connecting passengers, allocated comfort, and any notion that the base fare should cover the whole journey. That exclusion is what makes it a strategy. Organisational strategy is the set of choices about how work is arranged so that the business strategy can actually be executed. It covers structure and reporting lines, who decides what, how performance is measured and rewarded, which skills are hired or developed, and the harder-to-name matters of culture and norms that determine what people do when no rule applies. It is the design of work. When a firm says it has become "customer-centric" but still pays its sales force on units shifted this quarter, its organisational strategy has told the truth and its business strategy has not. Information systems strategy is the set of choices about the information capability the organisation will have: what systems it will run, who will use them and who will own them, where they will sit, how much will be spent on them, and in what sequence they will arrive. It is emphatically not a list of technologies. A genuine IS strategy is a plan for a capability, expressed in terms that a chief executive can argue with. The triangle's central claim is that these three are not three separate plans that happen to be produced by the same organisation. They are a single interdependent system. Move any one vertex and the other two must move in compensation, or the organisation goes out of balance. This is a stronger statement than it first appears, and it cuts in every direction. It is not merely that information systems must support the business strategy — that much is the conventional wisdom and it is only a third of the claim. It is equally that a change in information systems will force a change in the design of work whether anyone planned for it or not, and that a change in either information systems or organisational design can alter what business strategies are available to the firm at all. Zara is the standard illustration of the three vertices in coherence, and it earns the status. The business strategy is to sell fashion that responds to what is selling this week rather than what a designer predicted last season, at prices that make frequent purchase reasonable. The organisational strategy puts unusual authority in the hands of store managers, who report what customers are asking for and picking up and putting down, and keeps design, sampling and a substantial share of manufacturing close enough to be redirected within days. The information systems strategy supplies the fast, granular, store-level flow of sales and inventory data that makes the short cycle possible, and the logistics systems that move small, frequent consignments rather than large seasonal ones. Remove any one of the three and the other two stop making sense. Give a conventional retailer Zara's systems and it will produce excellent reports about a supply chain it cannot turn. Give Zara's organisational design to a firm with quarterly buying cycles and you have empowered a group of store managers to shout into a void. It follows that alignment is not a state that can be reached and then maintained by vigilance. Every vertex is under continuous pressure from outside. Competitors move, which changes the business strategy. Labour markets and regulation change, which changes organisational design. Technology changes on a cycle nobody in the firm controls, which changes what the IS vertex could be. Alignment is therefore a condition, like the balance of a walking person, rather than an achievement, like the summit of a hill. A walking person is never in balance and never out of it; they are continuously falling forward and continuously correcting. Organisations that appear well aligned are not those that got the answer right in a planning exercise three years ago. They are those whose correction cycle is short. The model behind the model The triangle is a teaching compression of a more careful piece of work: the strategic alignment model developed by John Henderson and N. Venkatraman in the early 1990s. Knowing the original is worth a good deal in an examination, because it lets you say what the triangle leaves out, which is the difference between a student who has memorised a diagram and one who understands a literature. Henderson and Venkatraman work with four domains rather than three. On the business side they distinguish business strategy from organisational infrastructure and processes. On the technology side they make the same distinction, separating information technology strategy — the firm's positioning in the external technology marketplace, its choices about scope, competences and governance of technology — from the internal IS infrastructure and processes, meaning the architecture, the systems that exist, the skills and the ways of working that deliver them. The four domains are then related along two dimensions. Strategic fit is the vertical relationship between what is decided about the outside world and what is built inside the firm to deliver it. Functional integration is the horizontal relationship between the business domains and the technology domains. The model's most useful contribution is its insistence that alignment can be driven from any corner. Henderson and Venkatraman set out several alignment perspectives, each defined by which domain is the anchor and which is to be changed. In one, business strategy drives organisational design, which in turn dictates what the IS infrastructure must be — the classic case, and the only one most students can describe. In another, business strategy drives IT strategy, which then reshapes the internal IS infrastructure, bypassing organisational design as the intermediate step. In a third, an emerging IT strategy makes new business strategies possible, and the business strategy is revised to exploit them. The perspectives differ in what is taken as fixed and what is treated as the outcome, and a firm may be operating under one of them without ever having chosen it. The triangle drops the internal-external distinction, collapses four domains into three vertices, and drops the named perspectives. What it gains in exchange is usability under pressure. Four domains with two orthogonal dimensions and several directional perspectives is a model you can teach but not use in a meeting; three vertices and a claim of mutual dependence is a question you can put to a chief operating officer in twenty seconds and get a revealing answer to. The compression is honest as long as you remember two things it hides. First, the vertices in the triangle are drawn as equals and the lines have no arrows, which is a deliberate refusal to say which vertex leads; the original model makes the direction of drive an explicit variable, and in analysis you should always say which way the causation is running in the case in front of you. Second, the IS vertex is doing the work of two of Henderson and Venkatraman's domains at once, which is why so many student answers slide between "the firm should adopt a cloud-first posture" and "the firm should replace its warehouse management system" as though these were the same kind of statement. They are not, and Chapters 4 and 6 separate them properly. Three signatures of a triangle out of balance Misalignment is not a vague condition. It presents in three recognisable forms, distinguished by which vertex moved first and which failed to follow, and each has its own symptom set and its own corrective move, as Table 1 sets out. Learning to tell them apart is the single most practically useful thing in this chapter, because the three require completely different responses and are routinely mistaken for one another. Table 1. The three signatures of a triangle out of balance. Signature What changed first How it looks from the business side Corrective move Strategy announced, systems unmoved Business strategy New direction declared, then nothing happens; timelines slip without explanation; the old business continues under a new name Fund and sequence the IS and organisational changes the strategy implies, or revise the strategy to what the capability allows System installed, work unchanged Information systems Go-live "succeeds" but benefits never appear; workarounds, shadow spreadsheets, duplicate data entry; users blamed for resistance Redesign roles, decision rights, incentives and measures around the new process; treat adoption as the deliverable, not the go-live Technology leading, strategy following Information systems Product and market choices quietly constrained by what the systems allow; "the system can't do that" becomes a strategic answer Make the direction of drive explicit: either adopt the technology-led strategy deliberately or reclaim the constraint as a decision The first signature is the announced strategy that changes nothing. A new direction is set at board level, communicated with conviction, and then absorbed without trace by an organisation whose information systems continue to support the previous strategy perfectly well. Blockbuster is the standard case. By the middle of the 2000s its leadership had identified the threat accurately and articulated a credible answer: abolish the late fees that customers resented, and combine the store network with a postal and eventually digital service so that a customer could return a disc in a shop and receive the next one by mail. What it required was a single view of a customer's account, inventory and entitlement across thousands of stores and an online channel, running as one system rather than two. The capability was never built at the necessary speed or coherence, and the organisational structure — a store network with franchised outlets whose economics depended on the very fees the strategy abolished — was not rebuilt around it either. The strategy was announced, the other two vertices stayed where they were, and the announcement turned out to be the whole of it. The diagnostic value here is that the symptom is not an IT symptom at all. Nobody reports a system failure. What is reported is unexplained slippage: initiatives that are always about to start, pilots that never scale, and a growing gap between the language used about the company externally and the work being done inside it. The corrective move is genuinely binary and should be stated as such in an essay. Either the organisation funds and sequences the systems and organisational changes the strategy implies, accepting the cost and the time, or it revises the strategy down to what its capability can actually deliver. The one thing it must not do is continue to announce a strategy it has not resourced, because that is how an organisation teaches its own staff that strategy is theatre. The second signature is the reverse: the system arrives and the organisation does not move. This is the most common failure in practice and the one most often misclassified as a technology problem. Lidl's long attempt to replace its inventory and merchandise management systems with an SAP-based platform is an unusually clear example, abandoned publicly in 2018 after some seven years and a sum widely reported to run into the hundreds of millions of euros. The technical account of the failure is well known: Lidl had for decades valued its stock at purchase price, while the standard retail package was built around valuation at retail price. The interesting question is what happened next. Rather than change a deep-seated internal practice to match a standard process that most of the industry used, the organisation directed that the software be customised to match the practice. Each such decision is individually reasonable and collectively fatal; the customisation burden grew until the programme could not be finished. The organisational vertex refused to move, so the IS vertex was bent to it until it broke. The everyday version of this signature is less dramatic and far more widespread. A system goes live on time and on budget, which is declared a success, and the benefits never appear. The tell-tales are always the same: workarounds, shadow spreadsheets maintained by the people who know what is really going on, duplicate entry into the new system and the old one, and a management narrative that settles on user resistance. Nike's problems with a new demand and supply planning system around 2000 followed this shape closely enough to have entered the textbooks — the system and the planning behaviour around it never became one process, and the consequences appeared in inventory and in a profit warning rather than in an IT incident log. The corrective move is to stop treating go-live as the deliverable. The deliverable is a changed way of working, which means redesigned roles, redrawn decision rights, and revised incentives and performance measures. If the measures still reward the old behaviour, the old behaviour is what you will get, and it will be reported as a software problem. The third signature is the quietest and the most dangerous. Here information systems change and business strategy follows them, without anyone deciding that it should. The technology sets the strategy by default. Marks & Spencer spent several years running its online business on a platform provided by Amazon, and the arrangement worked in the narrow sense that a functioning website existed. What it also meant was that the shape of the retailer's digital proposition — how customers were recognised, what could be personalised, how the online and store businesses could be joined — was bounded by decisions made by another company for its own purposes. The move to an in-house platform in 2014 was expensive and cost sales in the short term, and it was at bottom a decision to reclaim a strategic constraint that had been quietly delegated. Technology-led strategy is not inherently a failure. Amazon Web Services began as internal infrastructure work and became a business that changed the company's strategy and a great deal else besides; Netflix's investment in the systems that recorded what people actually watched shaped its commissioning decisions and moved it from distribution into production. Both were IS-led changes to business strategy, and both were deliberate. The signature is misalignment only when the direction of drive is unacknowledged — when a firm cannot enter a market because a core system cannot represent the product, and this is reported as a technical detail rather than as a strategic choice already made. The corrective move is not to reverse the direction but to surface it: to say plainly that the technology is leading, and then decide whether to adopt that strategy or pay to change the constraint. Turning "our IT is failing" into an answerable question The triangle's most valuable property is not explanatory but interrogative. "Our IT is failing" is not a question; it is a complaint with no possible answer, because it has no subject, no verb of change and no counterfactual. Run the same complaint through the triangle and it becomes a sequence of questions that can be answered with evidence: which vertex moved most recently; which of the other two has moved in response and which has not; what the specific compensating change would be; and who has the authority to make it. This is the whole method, and Chapter 10 develops it into a repeatable procedure for cases and essays. Notice what the reframing does to the politics. A complaint about IT is an accusation aimed at a department. A finding that the business strategy changed eighteen months ago and neither the systems nor the incentives have followed is a statement about the organisation as a whole, with a named corrective move and an owner who is usually not the chief information officer. Very few of the failures studied in this book are failures of technology. They are failures of compensating change, and the triangle's purpose is to make the missing compensation visible. Two errors will cost marks and, later, credibility. The first is treating the triangle as a checklist — walking through the three vertices, describing each one in turn, and concluding that all three exist. Every organisation has all three vertices; that is not a finding. The triangle is about the relationships, not the corners, and an answer that describes three vertices without analysing a single dependency between them has not used the instrument at all. The second error is treating alignment as work that the IT department performs on behalf of everyone else. Alignment is a joint condition of three sets of choices, only one of which the IT function owns. A chief information officer can align systems to a strategy that has been made explicit; none can align systems to a strategy that has not been decided, and none can redesign the incentives of a sales force. When alignment is delegated to IT, what is actually being delegated is the blame. What the examiner is looking for Markers reward three things in answers on the triangle, and the first is directional precision. Do not write that the vertices "must be aligned"; write which vertex moved, in what direction, when, and which failed to follow. An answer that identifies the sequence of change is doing analysis; an answer that asserts mutual dependence in the abstract is reciting a definition. The second is the ability to distinguish the three signatures and to attach the correct corrective move to each, since the remedy for a strategy that outran its systems is nothing like the remedy for a system that outran its organisation. The third is intellectual honesty about the model itself: the strongest answers note that the triangle is a compression of Henderson and Venkatraman's strategic alignment model, that the original treats the direction of drive as an explicit variable, and that the triangle's symmetrical drawing hides exactly that question. The reliable ways to lose marks are equally consistent. Describing the three vertices and stopping is the commonest. Assuming that the business vertex always leads is the second, and it is a substantive error rather than an omission, because it makes the technology-led signature invisible. Treating alignment as a project with an end date is the third. Using a case as decoration — naming a company and then not using it to demonstrate anything — is the fourth, and it is avoided by making every example do diagnostic work: say which vertex moved first. Three questions in the style you should expect: 1. "Alignment is a state that well-managed organisations achieve and then maintain." Critically evaluate this statement with reference to the Information Systems Strategy Triangle and to at least two organisations of your choice. 2. A retailer has announced a strategic shift to direct-to-consumer sales but reports that "IT cannot keep up". Using the triangle, diagnose the likely signature of misalignment, identify the evidence you would seek to confirm your diagnosis, and specify the corrective actions and who should own them. 3. To what extent does the Information Systems Strategy Triangle simplify Henderson and Venkatraman's strategic alignment model, and what analytical capability is lost in the simplification? Illustrate your answer with a case in which information systems drove business strategy. Chapter 2. Reading the Top Vertex: Business Strategy A student asked to analyse a case will often begin by describing the company: how large it is, what it sells, what it says about itself. None of that is a strategy, and an analysis built on it will not survive a marker's first question. The top vertex of the triangle asks something harder: what has this firm chosen to do, and what has it chosen not to do, in order to win customers at a profit its rivals cannot match? Until you can answer that in two or three sentences, you cannot say anything useful about the other two vertices, because organisational strategy and information systems strategy have nothing to be aligned to. The tools below are the standard ones, but the aim is not to recite them. It is to open a case, apply them, and emerge with a defensible statement of what the firm's strategy is and what that strategy obliges its information systems to deliver. What a business strategy is, and the three things that are mistaken for one A business strategy is a coordinated set of choices about where a firm will compete and how it intends to win there, made in the knowledge that those choices foreclose others. Porter's formulation is the most useful one to hold in mind: strategy is about deliberately choosing a different set of activities from rivals in order to deliver a distinctive mix of value. The word doing the work is different. If every firm in an industry pursued the same activities more or less competently, there would be no strategy in the industry, only a race in operational effectiveness — and such a race converges, because best practice diffuses. Three impostors appear regularly in student answers and in real corporate documents. The first is the mission statement. "To be the world's most customer-centric company", "to enrich lives through technology", "to be the partner of choice" — these are declarations of aspiration. They contain no choices, and strategy is precisely the part a competitor would decline to copy. Test any mission statement by asking whether a rival could plausibly adopt the opposite. No airline aspires to be the world's least customer-centric carrier; therefore customer-centricity is not a strategic position. The second is a list of goals: grow revenue, enter new markets, improve satisfaction scores, reduce cost-to-serve. These are outcomes the firm would like. A strategy is the theory of how they will be produced — the logic connecting choices to results. Goals without that logic are a budget with ambition attached, and the characteristic failure of organisations in this condition is that every function invents its own private theory of how to hit the numbers. IT invents one too, which is among the commonest origins of a misaligned technology portfolio. The third impostor is a technology. "Our strategy is to become a digital business", "our strategy is AI". Technology can be the instrument of a strategy, but on its own it specifies neither a customer nor a basis of advantage. A firm whose stated business strategy is a technology has collapsed the top vertex into the bottom-right one, and has no independent standard against which to judge its own IT decisions. Ryanair illustrates a real strategy because its choices are so visibly costly. A single aircraft type simplifies maintenance, training and spares at the price of route flexibility. Secondary airports cut landing fees and turnaround times at the price of convenience. Point-to-point flying removes connection complexity and abandons the transfer traveller. High-density seating and aggressive ancillary revenue raise yield per passenger and drive a segment of the market elsewhere. Every one is a trade-off, which is what makes it strategy rather than preference. A rival that admires Ryanair's costs cannot have them without accepting its renunciations. Three ways to win, and the quarrel about the middle Porter's generic strategies reduce the ways a firm can outperform its industry to a small number. Advantage comes either from lower cost or from differentiation customers will pay for, and it is pursued either across a broad market or within a narrow segment. That yields cost leadership, differentiation, and focus — focus splitting in turn into a cost-based and a differentiation-based variety. Cost leadership means being the lowest-cost producer while offering a product customers find acceptable. It is not the same as charging the lowest price; a cost leader may price at the market and bank the margin. Aldi is the cleanest retail example: a few thousand product lines where a full-range supermarket carries tens of thousands, mostly own-label, stocked from the pallet, in small stores with a lean head office. Each choice removes cost from the system rather than merely squeezing suppliers. Differentiation means offering something customers value enough to pay a premium for, and sustaining it. Apple is the obvious consumer case: integrated hardware, software and services, industrial design, a controlled retail experience, an ecosystem that raises the cost of leaving. Rolls-Royce's civil aerospace business is more instructive, because its differentiation is not the engine but what surrounds it. Under long-term service arrangements, airlines effectively buy thrust and availability rather than hardware, with Rolls-Royce retaining responsibility for maintenance. That contract is only writable because the firm instruments its engines and monitors their condition continuously; the differentiation is inseparable from an information system. Focus means serving a narrow segment so well that broad-line competitors cannot match you there. Brompton is a genuine niche player: folding bicycles for urban commuters, made in the United Kingdom, sold on a specific promise about how a bicycle behaves when it must be carried onto a train. A mass-market manufacturer could build a folding bike; it could not easily build Brompton's relationship with that customer or its knowledge of a hinge-critical frame. These positions place quite different demands on the systems that support them, as Table 2 sets out. The fourth column is the one to read closely: the strategy at the top vertex is not a mood, it is a specification. Table 2. The three generic strategies compared. Strategy Source of advantage What the customer is buying What it demands of information systems Exemplar Cost leadership Lowest cost position in the industry An acceptable product at an unbeatable price Process automation; supply chain visibility; low-cost standardised estate Aldi, Ryanair Differentiation Distinctiveness customers pay a premium for An experience, a brand, a guaranteed outcome Rich customer data; cross-channel integration; systems embedded in the offer Apple; Rolls-Royce civil aerospace Cost focus Lowest cost within one narrow segment Segment-specific value at low price Narrow, deep systems for one segment, not general-purpose breadth Ryanair on European short-haul Differentiation focus Deep fit with one segment's needs Specialist expertise and fit Segment knowledge; configuration support; direct customer relationships Brompton Porter's accompanying warning is that a firm which fails to choose becomes stuck in the middle: it carries the cost base of a differentiator without the price realisation, and faces the price pressure of a cost leader without the cost position. The argument is not arbitrary. Low cost demands standardisation, volume, restricted variety and tight overhead; differentiation demands variety, service, research and a willingness to spend. The activity systems conflict, so pursuing both produces a compromise beaten at both ends. Marks & Spencer's clothing business has been described in these terms for years, squeezed by value retailers below and sharper specialists above. The criticism is serious and you should be able to state it. Many admired firms appear to combine low cost with high quality. Toyota showed that defect reduction and cost reduction can move together rather than trading off, undermining the assumption that quality must be bought. Amazon sustains low prices alongside a service proposition — selection, delivery speed, returns — that customers treat as differentiating. There is also a methodological complaint: "stuck in the middle" is easy to apply after the fact. A firm that fails is declared to have been stuck there; a hybrid that succeeds is re-described as having had a dominant logic all along. A proposition that cannot lose is doing little analytical work. The defensible position, and the one that earns marks, is this. The trade-off between cost and variety is real, but it is a curve rather than a wall, and information systems have moved the curve. Zara combines moderate prices with a responsiveness most of the apparel industry cannot match, but only because point-of-sale data flows back from stores to designers in days rather than seasons, production runs are short and near the market, and logistics replenish twice a week. The modern hybrid is less a refutation of Porter than evidence that coordination costs fell. The consequence for the triangle is direct: a firm pursuing a hybrid is betting its strategy on its information systems in a way a pure cost leader is not, and if the systems underperform, the position collapses into exactly the middle Porter warned about. Five forces, worked through the grocery aisle The five forces model asks a different question. It is not about the firm; it is about the industry. Its claim is that average profitability is determined by five structural features, and that a firm's returns come from industry structure plus its position within it. Take grocery retail in a mature Western European market. Rivalry among existing competitors is intense, and structurally so. Market growth roughly tracks population and food inflation, so volume gains must come from other firms. Fixed costs — stores, depots, vehicles — are high, which punishes empty capacity and encourages price-cutting to fill it. The same branded goods sit on every shelf, so the chains are largely undifferentiated, and exit barriers are high because store estates are illiquid. The result is an industry where operating margins sit in the low single digits despite enormous revenue. Threat of new entry looks low if you only count barriers: scale economies in buying, distribution networks that take years and capital to build, planning constraints on sites, established brands. Yet Aldi and Lidl entered and took substantial share. Entry rarely occurs into an industry as a whole; it occurs into a position. Newcomers who accept the incumbents' model face the full barrier, while those bringing a different one face a much lower one. Amazon likewise entered through a different channel rather than the front door of the superstore. Bargaining power of suppliers is not uniform, and the commonest error is to treat suppliers as a single bloc. Fresh produce growers are numerous, small and often dependent on one or two buyers; their power is weak, which is why the United Kingdom created a Groceries Code Adjudicator to police how the chains treat them. Major branded manufacturers are in a different position entirely: a supermarket that does not stock the leading cola, detergent or spread has a visible gap and loses trips. The dispute between Tesco and Unilever in 2016 over price increases following sterling's fall, which briefly removed well-known products from Tesco's website, was this force being tested in both directions. Bargaining power of buyers is the force students most often misjudge. No individual shopper has negotiating power. But buyer power is not only about negotiation; it is about the cost of walking away, and grocery switching costs are close to zero. Price transparency is high and multi-chain shopping is normal, so the power is exercised in aggregate and continuously. Threat of substitutes means alternative ways of satisfying the same need, not alternative firms serving it the same way. Another supermarket is a rival, not a substitute — a distinction worth marks. The real substitutes for a weekly shop are eating out, takeaway delivery platforms, subscription meal kits and food-to-go formats, several of which have grown. The verdict matters more than the inventory. This is a structurally unattractive industry — intense rivalry, weak protection from one class of powerful suppliers, near-costless buyer switching, live substitutes — and it is not unattractive because the firms are badly run. Reading it that way tells you at once what information systems in this sector are obliged to deliver: relentless cost extraction through supply chain and store systems, since margin cannot be won on price; customer data good enough to create switching friction where the product cannot, which is the strategic logic behind loyalty schemes; pricing and category systems fast enough to respond within hours; and fulfilment capability for channels the store estate was never designed to serve. Two limitations deserve a sentence. The model is a snapshot that says little about how structure changes, and it assumes industries have clear boundaries — awkward where platforms blur them, since a delivery platform is channel, rival and substitute at once. From activities to capabilities: the value chain, VRIO, and the end of durable advantage The value chain disaggregates the firm into the activities by which it creates value, so that cost and differentiation can be located rather than asserted. Porter's primary activities are inbound logistics, operations, outbound logistics, marketing and sales, and service; his support activities are firm infrastructure, human resource management, technology development, and procurement. The difference between what customers pay and what the whole chain costs is margin. Note where information systems sit. They fall under technology development and firm infrastructure — the support layer. The consequences of that classification have been large and mostly unhelpful, because support activities are treated as overhead, and overhead is what organisations cut when results disappoint. Yet information runs through every primary activity: inbound logistics is unintelligible without supplier scheduling data, operations without inventory systems, outbound logistics without routing, marketing and sales without customer data, service without case and asset records. In many firms the primary activities are now executed by systems rather than merely recorded by them. A supermarket's replenishment is a decision made by software. Rolls-Royce's service activity, once a cost centre, became the product itself once engine data made outcome-based contracts possible. This produces one of the most reliable pathologies in cases: a firm cuts what its accounts call IT overhead, degrades what its value chain calls operations, then reports the consequences as unrelated service failures. Use the chain as a discipline. For each primary activity, ask what information it consumes, what it produces, and who else needs that output; where nobody passes it on, you have found either a redundant activity or a broken linkage. Nor does the chain stop at the firm's boundary: Porter's value system links supplier chains to the firm's to the buyer's, and much advantage sits in those joins — as when Walmart gives suppliers direct sight of store-level sales and lets them manage replenishment. The resource-based view turns the telescope round. Where Porter looks outward at industry structure, Barney looks inward and asks why firms in the same industry, facing identical forces, perform differently. The answer is that they control different bundles of resources and capabilities. A resource is something the firm has — a patent, a location, a data set, a plant. A capability is something it can reliably do, which requires people, processes and resources working together in a way nobody wrote down. Barney's VRIO test asks four questions of any candidate source of advantage. Is it valuable — does it exploit an opportunity or neutralise a threat? Is it rare? Is it costly to imitate? And is the firm organised to capture the value? Fail the first and it is a weakness; pass value but fail rarity and you have parity; pass value and rarity but fail imitability and you have temporary advantage. Pass all three and fail organisation and you have a wasted asset — the letter students forget, and the one that most often explains why a firm with a genuinely superior capability still loses. Work the test on a concrete case, separating the system from the capability. Consider a grocery loyalty scheme of the Tesco Clubcard type. The scheme itself — cards, points, a transaction database — is valuable, since it identifies the shopper and permits targeted offers. Rare? Not for long; Sainsbury's and others launched competing schemes, and a rival can buy the same technology from the same vendors. Costly to imitate? No. On the system alone the verdict is parity. Now test the capability around it: the accumulated practice of turning transaction data into decisions about range, pricing, store format, promotion and own-label development, with buyers and category managers who trust the analysis enough to act on it. Valuable, clearly. Rare, because it rests on years of data that cannot be bought retrospectively. Costly to imitate for three of Barney's classic reasons: path dependence, since the history accrues only in real time; causal ambiguity, since even insiders cannot fully specify which parts of the practice produce the result; and social complexity, since it lives in relationships between analysts and commercial staff. And organised, if the structure actually routes the insight to people with decision rights. That is the difference between a system and a capability, and it is why you should be sceptical whenever a case claims software confers sustainable advantage. Software is procurable: Ocado licenses its automated fulfilment platform to Kroger and to Morrisons, and the licensees get the platform, not Ocado's accumulated learning about running it. D'Aveni's argument is that all of this is less stable than it looks. In conditions he called hypercompetition, advantages are systematically eroded by rivals' countermoves, so competition becomes a sequence of temporary advantages rather than the defence of a durable position. Firms manoeuvre across cost and quality, timing and know-how, strongholds and financial resources, and each move invites a response that destroys the equilibrium the last one created. The implication is uncomfortable: the correct behaviour is not to fortify a position but to disrupt your own first. Apple cannibalised the iPod with the iPhone. Netflix cannibalised a profitable DVD-by-mail business with streaming, then cannibalised its dependence on licensed content with originals. Kodak, holding genuine digital imaging capability, declined to cannibalise film and was destroyed by the transition it had the resources to lead. Hold the claim with care. Not every industry is hypercompetitive — regulated utilities plainly are not — and the evidence that advantage erodes faster than it once did is contested rather than settled. But the directional point survives. If the top vertex moves every eighteen months while the organisational and technical vertices carry lead times measured in years — architectures, skills, contracts, culture — then misalignment is not an occasional accident. It is the default state, and re-balancing must be continuous rather than performed in an annual planning cycle. That obligation, more than any framework above, is what the business strategy vertex hands down to the other two. What the examiner is looking for Markers reward a small number of distinctions, and they are the same ones every year. The first is strategy against aspiration: an answer treating a mission statement or a set of targets as a strategy has failed at the first step. The second is rivalry against substitutes — competing supermarkets are rivalry, meal kits and restaurants are substitutes, and confusing them is the commonest error in this topic. The third is resource against capability, and within VRIO the letter O, dropped in most answers despite being the reason many firms fail to convert real advantages into returns. Three habits lose marks reliably. Describing all five forces at equal length and stopping, without a verdict on whether the industry is attractive and which force binds hardest — the model is an argument, not a checklist. Calling every large firm a differentiator. And asserting that a technology delivers sustainable advantage without running it through VRIO, when the honest answer is normally that the system is imitable and only the surrounding capability is not. Strong answers handle objections. If you use "stuck in the middle", acknowledge the hybrid cases and explain why falling coordination costs made some viable. If you use the five forces, note that it is a static model with assumed industry boundaries. Specimen questions of the kind examiners set: 1. "A mission statement is not a strategy." Using Porter's generic strategies, evaluate the business strategies of two named firms competing in the same industry, and explain what each strategy obliges its information systems to deliver. 2. Apply the five forces model to grocery retailing. Identify the force that most constrains industry profitability, justify your choice, and explain what your analysis implies for where firms in the sector should direct information systems investment. 3. "A competitor can buy the same system, but cannot buy the same capability." Critically discuss with reference to the resource-based view and VRIO, using at least one real example, and consider whether D'Aveni's hypercompetition thesis weakens the promise of sustainable advantage. Chapter 3. The Second Vertex: Organisational Strategy and the Design of Work A hospital buys an electronic prescribing system. The software is competent, the servers are sized correctly, the interfaces to the pharmacy stock system work. Eighteen months later, junior doctors are still writing on paper during ward rounds and entering the orders later, in batches, from memory, at the nurses' station. Nothing has failed technically. What has failed is the fit between the system and the way the work is organised: who does what, in what sequence, under whose supervision, and with what consequences for being slow. This is the ordinary shape of information systems failure, and it sits on the organisational vertex of the triangle. Students consistently under-weight this vertex: it is less glamorous than business strategy, less concrete than technology, and harder to revise from, because it has no single celebrated framework with a memorable name. The claim the triangle makes is symmetrical. An information systems strategy must be as consistent with the organisation's design as it is with its competitive strategy, and a system introduced without a corresponding change to the organisation will be quietly defeated by it. The three levers a manager can actually pull Organisational strategy, in this context, means the deliberate design of the organisation and of the work inside it. It is not the organisation chart, though the chart is part of it. It covers how people are grouped, who holds which decision rights, how performance is defined and measured, what is rewarded and what is punished, what beliefs are shared about how things are properly done, and — most concretely — how a piece of work flows from the moment it arrives to the moment it is finished. A manager has three levers available here, all distinct from the technology itself. The first is the set of organisational variables: structure, reporting lines, grouping, roles, decision rights and the design of work processes. These are the things that appear in an announcement. A firm can group by function, product, geography or customer segment; it can push a decision down to a store manager or reserve it for a category buyer in head office; it can create a role called "sales operations analyst" that did not exist before, or abolish a layer of supervisors. They are the levers with the fastest visible effect and the shortest half-life, because a structure can be redrawn in a weekend and undone in another one. The second is the set of control variables: measurement, evaluation, targets, incentives, reward and budget. What gets counted, who sees the count, what happens to a person whose count is poor, and how money is allocated on the basis of it. Control variables change more slowly than structures, partly because compensation plans are contractual and partly because changing them is politically expensive. They are also far more powerful, because they determine what people do when nobody is watching and the new system is inconvenient. The third is the set of cultural variables: values, beliefs and the shared assumptions that members of an organisation hold so deeply they no longer notice holding them. Culture is what tells a subpostmaster's regional manager, or a bank's operations director, whether an anomaly in the numbers is more likely to be a person at fault or a system at fault. In the UK Post Office's Horizon affair, the working assumption that the computer was reliable and the humans were not shaped the interpretation of every discrepancy for years. No chart contained that assumption and no control report displayed it, but it governed behaviour more tightly than either. The point of separating the three is diagnostic. A manager facing a problem on this vertex has these levers and no others, yet most managers reach instead for a fourth thing that is not on the vertex at all: the technology. Buying a system is fast, procurable, budgetable and visible; redesigning a bonus scheme is slow, contested and career-threatening. So the technology lever gets pulled alone, the other three are left holding the old behaviour firmly in place, and the result is a triangle out of balance with the symptoms presented as IT problems. Zara is the standard example of the levers being pulled together. The technology — point-of-sale capture, handheld devices in stores, a short data path from shop floor to designers and to the factories in and around Galicia — is not exotic, and competitors bought comparable systems. What is distinctive is the organisational design around it. Decision rights over what to reorder sit unusually close to store managers, who feed judgement as well as data back up the chain. Commercial teams are measured on responsiveness to current selling rather than on the accuracy of a forecast made a year earlier. And the culture treats a stockout as acceptable, even desirable, in a way that would be a firing offence in a traditional retailer measured on availability. Many retailers bought good replenishment systems in the same period and obtained very little from them, because the systems were installed into organisations whose buyers still committed the season's range in advance and were still rewarded for hitting margin on the plan. The incentive problem: why good systems go unused If you had to name a single cause for low adoption of otherwise sound systems, it would be misalignment between what the system asks people to do and what the reward system pays them for. Nothing else comes close — not usability, not training, not "resistance to change" as a personality trait. Take a worked example. A business-to-business distributor with some forty field sales representatives buys a well-known cloud CRM. The stated purpose is forecast accuracy: the finance director cannot plan working capital because the quarterly revenue forecast swings wildly, and the sales director cannot see which deals are real. The system requires each representative to maintain an opportunity record for every live deal, with a value, a close date, a stage and a next action, updated weekly. Now look at the representative's world. Their bonus, a large share of take-home pay, is paid entirely on closed revenue in the quarter. Nothing in the plan pays for the quality of the pipeline record, and maintaining it costs perhaps half an hour a week of time that could be spent selling — small, but strictly negative in reward terms. The cost is worse than the time, because the record creates exposure. A deal entered at a high value and then lost is a visible failure that was previously invisible. A well-populated pipeline invites a manager to raise the quota, or to reassign a fat account that is being under-worked. The rational representative therefore enters the minimum: deals effectively already won, at conservative values, with close dates pushed to the end of the quarter. The pipeline becomes a lagging record of what has already happened rather than a forward view of what might. Six months later the forecast is no more accurate than before, and senior managers conclude that the CRM has failed and the sales force needs more training. Both conclusions are wrong. The system works; it is faithfully recording the behaviour the compensation plan rewards. The defect lies in the control variables, and it was there before the software arrived. Fixing it requires pulling the levers that were left alone. On control: attach a meaningful share of variable pay to qualified pipeline coverage and to record completeness — while recognising that any such measure will be gamed, so "qualified" must mean something a second party verifies. On organisation: create a pricing approval step that cannot be reached except through a CRM record, so the system sits on the path to something the representative actively wants rather than beside it, and cut the cost of compliance by auto-capturing activity from email and calendar. On culture: run the weekly pipeline review from the system and only from the system. If it is not in the system it does not exist, and the first senior manager who accepts a side spreadsheet destroys the rule for everyone. The principle generalises well beyond sales. Whatever a system measures becomes a target, and whatever becomes a target distorts the behaviour it measures: call centres that measure average handling time get calls terminated early and customers who ring back. This is not a reason to avoid measurement, but a reason to treat a new measurement system as an act of organisational design, with the gaming response anticipated rather than discovered. Automating, informating and the shape of the hierarchy Shoshana Zuboff's distinction between automating and informating remains the most useful single idea on this vertex, and it is frequently misremembered as a choice between two kinds of system. It is not. It is an observation that the same system does both at once, and that management chooses which of the two it takes seriously. To automate is to substitute machine capacity for human effort: the task a person used to perform is now performed by the system, faster and more consistently. To informate happens as a by-product. Because the work passes through a system, it throws off a detailed record of itself — a stream of data about the process that did not exist when the work was done by hand. Ocado's warehouses automate the picking of groceries; they also informate, generating a minutely detailed account of demand, throughput and failure that the company has been able to sell as a service to other retailers. Rolls-Royce's instrumented aero engines automate very little of the engineer's work but informate intensely, and that data stream is what makes it possible to sell availability rather than hardware. The engineer's job changes from repairing what has broken to forecasting what is about to, and the commercial relationship with the airline changes with it. The organisational choice is about where the informating stream is allowed to flow. If the new data flows only upward, it becomes an instrument of central control and monitoring: head office now sees what the branch used to know privately, and the branch's discretion narrows. If it flows outward to the people doing the work, it becomes an instrument of upskilling: the operator who can see the whole process can be trusted with decisions that previously had to be escalated. The technology is identical; the organisational design is opposite. This is where the deskilling and upskilling debate belongs, and neither should be treated as the inevitable consequence of computerisation. Scripted contact-centre systems that route the agent through a decision tree genuinely deskill: they lower the knowledge required, which lowers the wage the role commands and raises the tolerable rate of turnover, and that is often exactly what the system was bought to achieve. Field service diagnostics that put the whole machine history in the engineer's hands genuinely upskill. Both are design decisions, taken by managers in pursuit of a business strategy — which is precisely the triangle's claim. A cost-leadership strategy pulls systems towards deskilling and standardisation; a differentiation strategy built on expert service pulls them the other way. Two structural consequences follow. The first is span of control. A supervisor who must inspect work personally can oversee a handful of people; a supervisor whose system reports exceptions can oversee many more, because attention is directed only where the process has departed from the expected. Widening the span of control is arithmetically the same thing as removing layers of hierarchy, and the wave of delayering in large industrial firms in the 1980s and 1990s — General Electric under Jack Welch being the most discussed case — was made practicable in part by management information systems that let fewer managers hold a larger territory. The under-noticed cost is that the middle managers who remain have a different job: unable to check everything, they have to coach, set direction and handle exceptions. Organisations that flattened without changing what they expected of middle managers simply produced overloaded supervisors performing the old job badly. The second consequence runs the other way, from organisation to system, and it is Conway's law: organisations design systems that mirror their own communication structures. A retail bank with separate, long-established business units for branches, telephone banking, the website and the mobile app will tend, over time, to build four customer records, four authentication mechanisms and four views of a balance — not because any architect chose that, but because each unit builds what it can build without negotiating with the others. The integration project that follows is described as a technical problem and priced as one, when it is really an attempt to undo an organisational boundary using software. Amazon's much-discussed insistence that internal teams expose data only through service interfaces, coupled with small autonomous teams, is best read as the deliberate inverse: designing the organisation in order to obtain the architecture. For the triangle, Conway's law is the sharpest statement of interdependence available. If you want a different architecture, you may first have to change the organisation that will build it. Distance, monitoring and the resistance that training cannot fix Hybrid and remote working is the live organisational-strategy question of the present decade, and it is routinely mishandled as a technology question. The technology settled quickly: video conferencing, messaging, cloud storage and virtual desktops are adequate and widely deployed, and the pandemic proved that most information work can be performed away from an office. What did not settle is the organisational design around them. Distance changes how work is coordinated, how people are supervised, how newcomers absorb tacit norms they previously picked up by proximity, how weak ties across departments form, how real estate is used and, awkwardly, whether pay should follow the local labour market of wherever the employee now lives. The technologies both enable and constrain. Persistent chat tools make lateral coordination cheap and interruption cheaper still. Video calls transmit content well and the informal, unplanned encounter badly. Document collaboration removes the version-control friction that made distributed writing painful, while the absence of a shared room removes the overhearing through which junior staff used to learn how a difficult negotiation is handled. The decisive point is a control-variable point. Supervision in an office rests substantially on presence: the manager infers effort from attendance and visible activity. Remove presence and that proxy is gone, and the organisation must either replace it with a defensible measure of output or find a substitute proxy. Many firms did neither, and the return-to-office mandates that followed — Amazon's move to a five-day office requirement being the most prominent — are best understood not as evidence about productivity but as a decision to restore the old proxy rather than redesign measurement. That may be defensible. It is not neutral, and it costs most in the labour market for exactly the staff who have alternatives. The substitute proxy many organisations reached for instead is electronic monitoring: activity scores derived from keyboard and mouse use, application-usage dashboards, idle-time reporting, screenshots, and in physical work the older machinery of rate tracking and "time off task" familiar from Amazon's fulfilment centres. Some of this is legitimate — a warehouse must know where a tote is, a trading floor must record communications by law. Some is corrosive. Barclays, in a widely reported case, installed desk-occupancy sensors and later a staff-tracking system, withdrawing the latter after objections from employees and attention from the regulator; monitoring decisions are governed as well as managed, and in Europe are constrained by data protection law and, in several countries, by works councils. The trust cost is the part students should be able to articulate. Monitoring communicates an assumption about the person monitored, and that assumption tends to be self-fulfilling. Where surveillance is close, discretionary effort — the unpaid extra that makes organisations function — falls, because the employee reasonably concludes that what is wanted is compliance with the measure rather than contribution to the outcome. The measured behaviour rises and the unmeasured behaviour, which frequently includes helping colleagues and flagging problems, falls. Monitoring is also distributed asymmetrically, heaviest on the lowest-paid and least autonomous workers and lightest on the executives who commission it, which is noticed. A defensible position is available: monitor the process for coordination and safety, evaluate people on outcomes, be explicit about what is collected and why, and give the resulting data to the worker as well as the manager — which is to say, informate outward as well as upward. All of this bears on what to do when a system is not being adopted, and here the reflex answer is almost always wrong. When usage is low, organisations run more training. Training is attractive because it is cheap, procurable and adjacent to the technology vertex, and because it converts a political problem into an informational one that nobody need be blamed for. It works only when the cause is genuinely a deficit of ability. The useful diagnostic separates three quite different situations. The first is cannot: people lack the skill or the time to use the system as designed, and training and workload relief are the right responses. The second is will not: people understand perfectly and are declining, because the system costs them time, status, autonomy or money, or makes visible something they preferred to keep private. No amount of training touches this; only the control and organisational levers do, by changing what the behaviour costs and pays. The third, and the one managers least like to consider, is should not: the objection is correct, and the system as configured makes the work worse or less safe. Clinicians who abandon an order set because it adds twelve clicks to an urgent prescription are not being obstructive; they are reporting a design fault. Resistance, on this reading, is not an obstacle to be overcome but information about a mis-designed system or organisation, and the first managerial duty is to establish which of the three it is before spending money. What does work, where the diagnosis is will not, is unglamorous. Involve the people who do the work in configuring it, so the design absorbs their knowledge and they own the result. Secure visible, repeated senior sponsorship, which John Kotter's work on change has long emphasised and which in practice means a leader who keeps asking about the system in public for longer than is comfortable. Close the escape routes: decommission the old system, withdraw the parallel spreadsheet, route a needed approval through the new process. Change the measures and the money so that using the system is the profitable behaviour, and give people time in the schedule for the transition rather than expecting it on top of a full workload. The sequence matters: the organisation usually has to move before, or at worst alongside, the technology, never a year afterwards. What the examiner is looking for Markers want a candidate who treats organisational strategy as a set of specific, nameable design choices rather than as "people issues" or "company culture" used as a residual category for anything unexplained. The strongest answers do three things. They use the three levers — organisational, control and cultural variables — as an explicit diagnostic frame, and say which lever is jammed in the case at hand. They distinguish automating from informating correctly, as two simultaneous properties of one system rather than two types of system, and draw the consequence about who receives the new data. And they trace interdependence in both directions: not only that a new system requires organisational change, but, via Conway's law, that the existing organisation shapes what system gets built. Marks are lost in predictable ways. Attributing non-adoption to vague "resistance to change" without identifying the incentive that makes refusal rational is the commonest. Treating deskilling as an automatic consequence of computerisation rather than a design decision serving a business strategy is another. So is recommending training as the remedy for every adoption problem, and describing monitoring as simply good or bad rather than weighing what it buys against the discretionary effort it costs. Use real organisations and say precisely which lever the example illustrates. Specimen questions: "A regional insurer has spent two years and a large budget implementing a new claims management system. Adjusters continue to keep their own spreadsheets and the system's data is incomplete. The IT director proposes a further round of training. Critically evaluate this proposal and recommend an alternative course of action." "'The same information system can deskill one workforce and upskill another.' Discuss, with reference to Zuboff's distinction between automating and informating." "To what extent is the choice between office-based, hybrid and fully remote working an organisational strategy decision rather than an information systems decision? Support your argument with examples." Hashtags: #TheInformationTriangle #StrategicManagementOfInformationSystems #InformationSystemsStrategyTriangle #BusinessStrategy #OrganizationalStrategy #InformationSystemsStrategy #StrategicAlignment #StrategicFit #FunctionalIntegration #HendersonVenkatramanModel #BusinessITAlignment #DecisionRights #OrganizationalDesign #ControlVariables #CulturalVariables #TechnologyGovernance #InformationSystemsCapability #CompetitiveAdvantage #PortersGenericStrategies #FiveForces #ValueChain #ResourceBasedView #VRIO #ContinuousRealignment #FutureOfStrategicInformationSystems