Kill switch and institutional capture

The promise that rests on the possibility of withdrawing it

In 2017, during Hurricane Irma, several Tesla owners in Florida discovered that their car, upon receiving a remote update from the manufacturer, suddenly gained additional miles of range. They hadn't paid for them. The battery had always been able to deliver them; the manufacturer had decided, in order to segment the market, not to allow the customer to have them. During the emergency, Tesla temporarily activated the full capacity. Once the emergency passed, it deactivated it.

What the news described as a gesture of generosity was, read slowly, something else. The owner had never owned the entire product they paid for. The manufacturer retained a technical capability —to expand or reduce features remotely— and chose to exercise it in favor of the customer in that specific case. They could have chosen the opposite. The story doesn't tell of an act of kindness; it tells of a power architecture.

This article deals with that architecture. We call it, by industry convention, kill switch: the remote switch that allows the operator to deactivate, modify, or withdraw capabilities of a product, service, or device that the user already believed was theirs. The question is not whether the operator is honest. The question is what happens when they stop being so, or when someone forces them to use the switch in another direction.

What exactly is a kill switch

The term comes from English and is difficult to translate: interruptor de muerte sounds dramatic; interruptor remoto sounds too neutral. What defines the kill switch is not the drama, but a simple property: the technical capacity to deactivate something remotely, in the hands of someone other than the user. It can be a complete shutdown —the car that won't start, the file that is deleted, the account that is suspended— or a partial shutdown —the function that disappears, the battery that loses range, the subscription that is interrupted.

Not all remote control is a kill switch. A routine security update, authorized by the user upon installing the product, is not. Neither is an anti-theft system activatable by the owner when their phone is stolen. The kill switch, in the proper sense, has three traits: its use is the operator's decision, not the user's; it does not require specific consent from the affected party to be activated; and it is exercised over a product or service that the user already considered fully theirs.

The European gallery of active switches

Tesla repeats the pattern frequently, in its case in a documented way: contractual degradations of range applied to second-hand vehicles that changed owners, removal of assisted driving functions after license revocation, unilateral modifications of product behavior between firmware versions. John Deere has been at the center of the European and American debate on the right to repair for years: the tractor purchase includes a software layer whose service depends on the manufacturer's official network; when that network denies registration, the tractor reduces essential functions. BMW offered a monthly subscription in 2022 to activate seat heating in cars that already had it physically installed; public pressure forced the withdrawal of the model, but the technical capacity remains.

In the software realm, the pattern is structural. Adobe Creative Cloud revokes monthly licenses when the subscription is not renewed, leaving files created by the user with those tools unusable. Microsoft can deactivate copies of Windows that it considers non-genuine, without practical recourse. Google removes applications from the Play Store complying with court orders or internal decisions; the uninstalled application is also uninstalled from the phones where it was. Apple Pay was deactivated in Russia in March 2022 as Apple complied with international sanctions: legitimate in the context, but the procedure was always available.

The legitimate argument on the manufacturer's side

Whoever designs one of these systems usually offers perfectly valid arguments:

1. Theft prevention. If my car or phone is stolen, I appreciate that the manufacturer can disable it remotely.
2. Fraud prevention. Unpaid subscriptions require a cutoff mechanism; without that mechanism, the business model collapses.
3. Prevention of misuse. A dangerous tool in the wrong hands can benefit from being able to be revoked.
4. Regulatory compliance. Certain legal orders compel the operator to remove content, disable features, or suspend accounts, and a system without a switch is a system that cannot comply with them.

All four arguments are true. None change the nature of the matter. It is true that a kill switch facilitates theft prevention; it is also true that this same capability serves to coerce the living customer, not just to harm the thief. It is true that the subscription model needs a cut-off; it is also true that the cut-off can be executed tomorrow on a current customer for a reason other than that provided for in the contract. The question is not whether the kill switch has legitimate uses. The question is that, once it exists, its uses are not limited to those foreseen in the initial documentation.

Institutional capture

Here enters the concept that gives the article its title. Institutional capture is the situation in which an actor — a private company, an administration, a regulatory body — ends up exercising capabilities it acquired or was granted for limited purposes for broader, different, or frankly opposite purposes to the originals. Political economy has known the phenomenon for decades in financial regulation. The technology industry is discovering it firsthand.

The mechanism is as follows. The company designs the kill switch for legitimate purposes: anti-theft, subscription management, compliance. The company documents these purposes in its terms of use, in its privacy policy, in its public messages. Years pass. A government issues an order under new legislation; the company is forced to use the switch in a direction not described in its original documentation. An activist shareholder enters the board and modifies the commercial policy; the switches exist, and are applied according to the new policy. The company is acquired by a larger one; the terms of service are rewritten unilaterally with thirty days' notice. In each case, the customer who trusted the switch for the documented purposes finds that the switch is still there, but responds to other interests.

The paradigmatic case for the European reader: the Apple vs. FBI case in San Bernardino, in 2016. After an attack in California, the FBI demanded Apple unlock an iPhone belonging to the perpetrator. Apple refused, sustaining partly arguments of principle and partly a technical argument: the system, as designed, did not allow the company itself to unlock the device without rewriting the base software. The most solid defense was not moral; it was architectural. Apple did not stand on the promise not to flip the switch; it stood on the absence of the switch. Other companies, with switches present in their architecture, have been unable to sustain the same position in the face of equivalent pressures.

The European regulatory trajectory

European law, in the last legislative term, has been pushing toward more remote control capabilities, not fewer. The Digital Services Act (DSA), fully applicable since February 2024, obliges platforms to enable rapid mechanisms for content removal under order of competent authority; mechanisms that would not exist without the underlying technical capability. The Artificial Intelligence Act (AI Act), in force progressively since August 2024, requires providers of certain high-risk AI systems to have measures allowing for their deactivation or significant human supervision: a regulatory form of mandatory kill switch. The Digital Markets Act (DMA) introduces, in contrast, interoperability obligations: an opposite current that limits lock-in effects.

For the European professional, the honest reading is the following: the question "can the operator deactivate this service for me?" has more affirmative answers every year due to legal requirement, not fewer. This does not question the legitimacy of the regulations —the DSA responds to real problems—, but it does reinforce one thing: trusting that the operator will not use the switch requires trusting, in addition, that no future legal obligation will force them to use it in a direction that is not contemplated today. It is a trust that does not rest only on the company; it rests on the entire regulatory environment.

The design question that is rarely asked

Most contemporary technical design assumes that the switch will exist and then promises not to abuse it. There is an alternative, more demanding but perfectly feasible: to design assuming that the switch must not exist. It is not a slogan. It implies concrete decisions: distributed versus centralized architecture, rights on the user's device versus account-derived rights, content encrypted with keys that the operator does not have versus content encrypted with keys that the operator keeps, cryptographic identity of the user versus identity managed by the operator. Each of these decisions has a real technical cost and real commercial consequences. But they all share a property: once taken, they eliminate certain legal orders as a possible object. What cannot be executed cannot be ordered to be executed.

For the Professional Reader

Five questions that should be asked of the provider of any critical professional service before adopting it, formulated in the order a business continuity inspector would pose them:

1. Does the technical capacity of the provider exist to suspend, block, delete or degrade my service, data or product remotely?
2. Under what contractually declared assumptions can the provider exercise that capacity?
3. Under what undeclared assumptions —judicial order, international sanction, unilateral policy change, corporate acquisition— can they exercise it as well?
4. If exercised, what time of continuity of professional activity do I have, and what exit plan is available?
5. Is there an architectural alternative where the answer to question one is "no" by construction, not by promise?

The answer to question five is not always available or proportionate. A personal spreadsheet probably does not merit that requirement. An active legal file, a patient's medical history, tax accounting, a deontologically protected conversation, yes. Proportionality is a professional decision; the honest reading of question one is not: either the switch exists, or it does not.

---

Protection that retains the possibility of withdrawal is not structural protection; it is renamed trust. Trust, as we have said in another Notebook, is a valid social solution when granted to those who deserve it, but fragile at the first change of hands. The cleanest structural defense is the one that cannot be withdrawn because it does not exist in the first place. As with everything in architecture: a design choice, not a marketing decision.