Who Can Stop This Car? How Titan Authorizes a Remote Immobilize Command
Titan exists to stop a vehicle from being driven away by the wrong person. That is a serious power to put in software, and it raises a question every customer should ask us, and every vendor like us: who is allowed to use it?
If the answer is "anyone with a login", the product is a risk. A command that can stop a vehicle has to be harder to misuse than the theft it prevents. This article explains how we answer that question today in the Partner Service Dashboard, where rental operators manage their vehicles.
I'll describe how it works at the level a customer needs to judge it, not at a level that would help anyone attack it.
One Command, Start to Finish
Say a location manager believes a vehicle is being taken by force and decides to immobilize it. Here is what happens.
- A person starts it. The command is sent by a named user signed in to the Partner Service Dashboard, never by a shared account.
- They confirm it. Immobilize is never one click. The dashboard opens a confirmation step that explains what the command will do before the person confirms.
- The platform checks it. Before anything is sent, the platform checks that the person's account is active, that their role is allowed to send this command, and that the vehicle is one they are responsible for.
- The vehicle receives it. Only a command that passes every check is sent to the Titan unit in the vehicle.
- The result is recorded. The command, the person who sent it, their reason and the time are logged, along with the result the vehicle itself reports back.
If any check fails, the command is refused and nothing is sent to the vehicle.
Who Is Allowed
Access in the Partner Service Dashboard is set per user, per role and per vehicle.
- Roles. An account can have an owner, location managers and operators. Operators handle the day-to-day work of a location. Immobilize is limited to the owner and location managers.
- Scope. A user's authority covers the vehicles and locations they are responsible for, not every vehicle in the account.
- Active accounts only. A deactivated user cannot send commands. If someone's permission is removed after they schedule a command, the scheduled command is skipped rather than sent.
The aim is simple: the number of people who can stop a given vehicle should be as small as it can be while still letting the business run.
The account owner decides who joins the account and what role each person has. My advice to every operator is the same: review that list whenever someone changes jobs or leaves, the same way you would collect their keys.
A Human Always Decides
Titan never immobilizes a vehicle on its own.
Our platform watches for things that look wrong, such as a vehicle leaving a zone it should stay in. When that happens, it raises an alert and opens an incident for a person to look at. It does not send a command. Deciding to stop a vehicle is a judgment about a real situation, with real people in it, and that judgment belongs to a person who is accountable for it.
That matters most for the customer who is doing nothing wrong. A late return, a wrong turn or a delayed flight should never stop a vehicle by itself.
When the Vehicle Waits, and When It Doesn't
Most of the time, a Titan unit protects a vehicle by being armed. Arming is how a vehicle is held between rentals, so it can't be driven away until the next rental is confirmed.
An arm command never stops a vehicle on the road. The unit in the vehicle waits until the vehicle is stopped and the ignition is off before it applies the lock. That rule is enforced on the vehicle, not only in the cloud. Our platform also holds back an arm command for a vehicle that is moving.
Immobilize is different, and I want to be clear about it. It exists for one situation: a vehicle that is being taken by force, right now. Waiting for that vehicle to park could mean it is never seen again. So Immobilize does not wait, and the dashboard says so plainly before the person confirms. That is exactly why it is limited to the owner and location managers, why it always needs a confirmation, and why it is never automatic.
Everything Is Recorded
Every command leaves a record: who sent it, when, why, which vehicles it was sent to and what each vehicle reported back. The result comes from the vehicle itself, not from an assumption that a command sent was a command applied.
Security activity in the dashboard can be exported, so an operator can hand a clear record to an insurer or to police: who did what, when and why. A log that can't be read outside the product isn't much use when it matters.
How We Keep It Honest
Describing safeguards is easy. Keeping them true takes ongoing work. This article describes what the product does today, not what we plan to build. When we find something that falls short of what we have written here, we fix the product or we fix the article.
Changes to our platform are reviewed before release, and we test our own platform, including with AI-assisted security review. We would also rather hear about a weakness from a researcher than from an attacker, so we publish a vulnerability disclosure policy and ask researchers to report what they find. I explain why in Why We Want Researchers Looking at Our Products, and the policy itself is on our Security page.
If you run Titan and want to know exactly who on your team can send which command, ask us. That is a question you should be able to answer at any time.
Recovery is too late. But prevention only works if people can trust who is allowed to use it.
For more on why acting early matters, read The Theft Starts at the Counter and GPS Tracking Can’t Stop a Car That’s Already Gone.
