UK Vehicle Security Data Risk, Renewal and Control Framework.

Section 01

Vehicle Security Data as a Risk Class

Vehicle Security Data is the information, credential or access pattern that allows a vehicle’s original security systems to be operated, bypassed, renewed, programmed or replicated.

In practical terms, VSD exists across both mechanical and digital environments. Mechanical VSD may exist in a key blade, lock barrel, key number or physical decoding pattern. Digital VSD may exist in an electronic key, transponder, immobiliser system, ECU, body-control module, remote locking system, keyless entry function, diagnostic access process or programming pathway.

The earlier VSRF proposal defined VSD as information relating to a vehicle’s original security systems, including keys, locks and electronic control units. It further distinguished between Mechanical VSD and Digital VSD, with Digital VSD carrying greater risk because it may enable both access to and starting of a vehicle.

That distinction remains useful, but the updated research context suggests the category should now be treated more broadly. Vehicle security data is not only “data” in the narrow database sense. It may be a code, credential, key profile, signal, token, programming state, immobiliser authorisation, stored key identity, mechanical pattern or exploitable access condition.

The important feature is not its technical format. The important feature is its effect.

If the information allows a person, device or system to access, unlock, start, reprogram or interfere with the vehicle’s security state, it is security data.

1.1 Why VSD is different from ordinary vehicle risk

Most vehicle risks are visible, inspectable or testable.

A worn tyre can be measured. A damaged panel can be seen. A fault code can be read. A failed MOT can be checked. A finance marker can be searched. A service history can be reviewed.

Vehicle Security Data is different.

A vehicle may have two keys, clean bodywork, no visible damage, no warning lights and a normal service history, while still recognising an additional active key or while still being vulnerable because a prior credential, code, signal pathway or access method remains available outside the current keeper’s control.

This creates an evidential problem. The current keeper may believe they control the vehicle because they possess the vehicle and its supplied keys. But possession of keys is not the same as sole control of vehicle security data.

Police guidance already recognises part of this issue. Police.uk advises drivers to reprogramme keys when buying a second-hand car and gives specific guidance for keyless-entry vehicles, including keeping keys away from the car, using signal-blocking pouches and turning off wireless signals where possible.

That advice is significant. It implicitly recognises that vehicle security risk may survive the sale of the vehicle. It also recognises that the buyer may need to take a positive control step after purchase.

However, advice is not the same as a formal control environment. It does not create a vehicle-level evidence record. It does not certify who performed the work. It does not state how many active keys or credentials remained afterwards. It does not give an insurer, buyer, fleet operator or future owner a reliable audit trail.

1.2 Mechanical VSD

Mechanical VSD is the physical security information that allows a vehicle lock to be operated or reproduced. It may include the key blade profile, lock wafer configuration, key code, key identification number or other lock-decoding information.

Mechanical VSD can be compromised where a key is lost, stolen, photographed, decoded, duplicated or retained by a previous user. It may also be exposed where a lock is picked, decoded or accessed during repair.

The principal risk created by compromised Mechanical VSD is unauthorised access. In many modern vehicles, mechanical access alone may not allow the vehicle to be started because the immobiliser system requires separate digital authorisation. However, unauthorised access can still create meaningful harm: theft from vehicle, access to documents, access to tools, access to goods, tampering, stalking risk, employee safety risk or preparation for further theft.

Mechanical VSD is therefore not obsolete. It remains part of the security picture, particularly for used vehicles, commercial vehicles, vans, plant-support vehicles and any vehicle where access to contents has material value.

1.3 Digital VSD

Digital VSD is the electronic security information or credential environment that allows a vehicle to be unlocked, started, authorised, programmed or reconfigured.

This may include electronic key data, transponder credentials, immobiliser authorisation, ECU-held key records, remote locking data, keyless entry signals, diagnostic security access, software-enabled authorisation and related electronic states.

Digital VSD is the higher-consequence category because compromise may enable both access and theft. It can also be harder for ordinary users to understand. A missing physical key is visible. A retained digital credential, cloned key, emulated signal or compromised programming state may not be.

The market already recognises that security-related digital access requires governance. SERMI UK describes its purpose as approving and authorising independent garages and service providers to obtain manufacturer-level access to security-related vehicle information, including processes such as programming keys and unlocking immobilisers.

That recognition matters. If legitimate key programming and immobiliser access require authorisation, then the underlying risk is not speculative. The market already accepts that security-related repair and maintenance information is sensitive.

The unresolved issue is what happens outside that controlled environment.

Section 02

How Vehicle Security Data Becomes Exposed

Vehicle Security Data can become exposed through lawful, semi-controlled, uncontrolled or criminal pathways.

Not every access event is improper. Vehicles require legitimate maintenance. Keys need replacing. Immobilisers require programming. ECUs may need repair. Independent operators need fair access to manufacturer repair information. Used vehicles need servicing. Fleet vehicles need operational flexibility.

The issue is not that VSD is accessed.

The issue is that once VSD is accessed, copied, decoded, retained or inferred, the current keeper may have no reliable way to determine whether that exposure has been neutralised.

2.1 Controlled legitimate access

Controlled legitimate access exists where authorised dealers, manufacturers, approved repairers or properly accredited independent operators access security-related repair and maintenance information for lawful purposes.

SERMI is important in this context because it creates a recognised access-control environment for independent operators. Its purpose is to support access to security-related information while maintaining a structured authorisation process.

This creates an important research finding:

The legitimate market is moving toward controlled access to security-related vehicle information, but vehicle owners still lack a consistent downstream control record for the vehicle itself after security-data exposure.

In other words, operator access may be controlled, but vehicle lifecycle risk may still remain unresolved.

2.2 Professional aftermarket access

A second layer exists in the professional aftermarket. Vehicle locksmiths, diagnostic technicians, module repairers, auto electricians and vehicle security operators may use tools capable of accessing, programming or altering security-relevant systems.

Many of these activities are lawful and necessary. Without them, vehicle owners would struggle to replace keys, repair immobilisers, restore access after key loss, recover from theft attempts or maintain vehicles outside franchised dealer networks.

However, the same class of capability creates a control problem. A tool that can lawfully programme a replacement key can also create risk if used by the wrong person, used without proper records, used outside a trusted environment, or used in a way that leaves the current keeper uncertain about the vehicle’s final security state.

This is not a criticism of the legitimate aftermarket. It is a reason to distinguish trusted, traceable and evidenced security work from unevidenced security access.

2.3 Criminal and uncontrolled access

The third layer is criminal or uncontrolled access. This includes relay attack equipment, signal jammers, key-emulation devices, CAN-bus attack tools, ECU-related compromise, stolen keys, cloned keys, illicit programming and model-specific theft technology.

The Home Office has stated that electronic devices are used by criminals in 40% of vehicle thefts in England and Wales, and that organised criminals seek ways to overcome security measures even in newer vehicles by exploiting vulnerabilities and technologies.

RUSI’s 2025 report on organised vehicle theft similarly frames contemporary vehicle theft as increasingly associated with sophisticated keyless theft methods, theft-to-order activity and organised criminal markets rather than only opportunistic offending.

This changes the risk environment. The threat is no longer limited to a stolen key or forced entry. The threat includes access capability that may be obtained, purchased, shared, adapted or deployed through criminal networks.

The result is an asymmetry:

Security-related vehicle access is sensitive enough to require control in legitimate repair environments, but criminal and uncontrolled markets can still obtain or deploy tools capable of attacking the same broad risk class.

That asymmetry is the reason a vehicle-level control mechanism becomes important.

2.4 Why this creates a lifecycle risk

Vehicle security data is not static. It travels through the vehicle lifecycle.

A new vehicle begins in a relatively controlled state. The manufacturer, dealer and first keeper are usually the principal parties connected to its security data. Over time, that changes. The vehicle may be sold, part-exchanged, repaired, recovered, leased, rented, shared, used by employees, used by contractors, stolen, broken into, repossessed, salvaged or exported.

Each event may increase uncertainty.

The original VSRF proposal described these moments as Exchanges of Control: occasions where a vehicle is made available to a party other than the legal owner or keeper. It argued that used vehicles and commercial vehicles may carry increased VSD uncertainty because the current keeper cannot reliably know the full history of access, possession or retained keys.

The concept remains central.

A vehicle does not need to be visibly damaged to be security-compromised. It only needs to have passed through a point where security data may have been copied, retained, accessed or left active outside the current keeper’s control.

That is the heart of the issue this paper will develop.

Section 03

Vehicle Theft, Electronic Compromise and Organised Crime

Vehicle security data risk cannot be understood only through the lens of individual key loss or individual vehicle misuse. The wider vehicle-crime environment has changed.

Modern vehicle theft increasingly involves a combination of traditional offending, electronic compromise, organised criminal demand, online tool availability, vehicle-specific knowledge and rapid post-theft disposal routes. The practical result is that vehicle security is no longer only a question of whether a door can be forced or a key can be stolen. It is also a question of whether the vehicle’s access, authorisation or immobiliser environment can be replicated, bypassed or manipulated.

This matters because Vehicle Security Data is the common thread that connects many of these risks. Whether the compromise involves a stolen key, a retained key, a cloned key, a remote-locking signal, an immobiliser credential, an ECU access pathway or a key-emulation device, the central issue is the same: a party other than the current keeper may be able to access or control the vehicle.

3.1 Historic security improvements reduced vehicle theft

The historic vehicle-security lesson is clear. When systematic security improvements are introduced at scale, vehicle theft can fall.

The original VSRF proposal relied on the 2016 Home Office study, *Reducing criminal opportunity: vehicle security and vehicle crime*, which examined how security improvements such as steering column locks and electronic immobilisers contributed to long-term reductions in vehicle crime. The earlier proposal also noted the Home Office concern that technological compromise could change the risk environment again if knowledge and equipment spread beyond more experienced offenders.

That historic point remains important. Vehicle theft is responsive to systems. It is not only responsive to punishment, consumer advice or insurance pricing.

When the vehicle ecosystem introduces a strong control - steering locks, immobilisers, improved manufacturer design, better access governance - crime opportunity changes. When criminals develop methods to bypass or commoditise that control, the opportunity reopens.

The research issue is therefore not whether vehicle security can ever be improved. It can. The issue is whether the present risk environment has created a new gap that existing controls do not fully cover.

3.2 Vehicle theft has re-emerged as a major risk class

Contemporary evidence suggests that vehicle theft has re-emerged as a serious problem after earlier decades of decline.

RUSI’s 2025 research on organised vehicle theft reports that UK vehicle theft had declined during the two decades before 2013, but that this trend later reversed, with Home Office data indicating a 75% increase in vehicle theft over the past decade. RUSI links that increase to technologically enabled theft methods, organised vehicle theft and international disposal markets.

Official statistics require careful handling because “vehicle-related theft” can include theft of vehicles, theft from vehicles and vehicle interference, and because police-recorded crime and Crime Survey estimates measure different things. ONS material also shows that vehicle-related theft can move down in some recent periods while still remaining a substantial incident category. The ONS year ending June 2025 bulletin reported a 13% decrease in vehicle-related theft to around 649,000 incidents, which is relevant because the paper should avoid implying that every metric is rising at all times.

The balanced research position is therefore:

Vehicle theft and vehicle-related theft remain material risk categories. Some recent incident estimates may fall, but the structural risk created by electronic compromise, organised crime and security-data uncertainty remains unresolved.

The paper should not depend on a simplistic claim that theft is always rising. Its stronger claim is that the nature of the risk has changed.

3.3 Electronic compromise is now mainstream enough to attract legislation

Electronic theft devices have moved from specialist concern to public-policy concern.

The Home Office has stated that electronic devices are used by criminals in 40% of vehicle thefts in England and Wales, and that organised criminals continue to look for ways to overcome security measures in modern vehicles by exploiting vulnerabilities and technologies.

This is a significant source point. It means the state now recognises electronic theft devices as a material driver of vehicle crime, not as an edge-case concern.

The same policy direction also confirms a deeper issue: enforcement is now trying to control possession, supply and use of tools, not only the act of theft itself. That implies that the capability market has become part of the risk environment.

In practical terms, the presence of tool-control legislation supports the following research finding:

Where access tools become sufficiently available, portable and capable, vehicle security risk cannot be assessed only by looking at the physical vehicle. The surrounding capability market becomes part of the security environment.

3.4 Common electronic and data-led compromise methods

The modern theft environment includes several method categories that are relevant to Vehicle Security Data.

Police.uk guidance reflects the mainstream nature of some of these risks. It advises owners of keyless-entry cars to keep keys away from the vehicle, use signal-blocking pouches, reprogramme keys when buying a second-hand car, and turn off wireless fob signals where possible.

That guidance is useful, but it also shows the limitation of the current environment. It gives owners steps to reduce risk, but it does not create a formal record that the vehicle’s security status has been assessed, renewed or controlled.

3.5 Organised crime changes the control requirement

Vehicle theft is not only opportunistic. Organised criminal groups can create demand, specialise by vehicle type, share methods, acquire devices, exploit online markets, move vehicles across regions or borders, and convert stolen vehicles into parts, cloned identities or export assets.

RUSI notes that organised criminal groups have developed sophisticated theft tools while conventional methods still persist, and that vehicle theft increasingly involves rapid theft, identity masking and resale or export channels.

This creates a different control problem from ordinary theft prevention.

A private owner can use a Faraday pouch. A fleet operator can improve key storage. A manufacturer can improve design. Police can target offenders. Insurers can price risk.

But organised crime exploits gaps between those systems.

That is why the VSD issue should be treated as a lifecycle control problem. The question is not whether every criminal tool can be eliminated. The question is whether a vehicle that has been through a risk event can be brought back into a known, evidenced and controlled security state.

3.6 The electronic-tool market exposes a gap between prevention and recovery

Tool bans and criminal enforcement may reduce the availability or use of some theft devices. They do not, however, answer the vehicle-level question after exposure.

If a vehicle has been stolen and recovered, who confirms whether its digital security state remains compromised?

If a key was lost, who confirms whether the missing credential remains active?

If a used vehicle is bought with one key, who confirms whether other active keys or credentials remain recognised by the vehicle?

If a fleet vehicle has passed through multiple users, who confirms whether security access has been restored to the current operator?

If a diagnostic or programming event occurred, who confirms whether the result is secure and evidenced?

These are not questions of general theft prevention. They are questions of post-exposure control.

The absence of a consistent answer is the basis for the paper’s next finding:

Vehicle theft can be policed. Security products can be improved. Tool markets can be restricted. But none of those measures automatically creates a vehicle-level record showing that exposed Vehicle Security Data has been renewed, revoked or controlled.

Section 04

Exchange-of-Control Risk

Vehicle Security Data risk becomes most visible when control of the vehicle, its keys, its security credentials or its repair environment passes from one party to another.

The original VSRF proposal described this as Exchange of Control. It defined an Exchange of Control as any occasion in which a vehicle is made available to a party other than the legal owner or keeper, and argued that such events create uncertainty over whether Vehicle Security Data has been compromised.

That concept remains central to the updated research paper.

An Exchange of Control does not need to involve wrongdoing. A vehicle may pass between parties for ordinary and legitimate reasons: sale, hire, lease, repair, recovery, employment, insurance, storage, remarketing or shared use.

The risk arises because each transfer may create exposure, and the current keeper may not have an effective way to verify whether that exposure remains active.

4.1 New vehicle baseline

A new vehicle normally begins from the strongest security-data position.

The manufacturer, dealer and first keeper are the principal parties connected to the vehicle’s security credentials. The vehicle is usually supplied with known keys. Its ownership and access history is short. There may be fewer unknown parties who could have retained active access.

This does not mean new vehicles are immune to theft. Modern vehicles can still be vulnerable to relay theft, key emulation, software weakness, CAN-bus attacks or stolen keys.

However, from a VSD lifecycle perspective, a new vehicle usually has a clearer baseline than a used vehicle. The access history is narrower and easier to explain.

The research implication is:

New vehicle security is primarily a design, storage, key-management and theft-prevention issue. Used vehicle security is additionally a historic data-control issue.

4.2 Used vehicle sale

Used vehicle sale is one of the clearest Exchange-of-Control risk points.

A buyer may receive one key, two keys or several keys. The number of keys physically supplied does not necessarily prove how many active credentials exist. A seller may be honest but unaware of historic security exposure. A previous owner may have retained a key. A lost key may remain active. A third party may have cloned or copied access. A key may have been replaced without record. A vehicle may have been repaired or recovered without a clear security-data audit trail.

This produces a market asymmetry.

The seller may not know the full security history. The buyer cannot easily verify it. The insurer may later ask for key evidence after theft, but key possession at claim stage does not prove that no third party had retained active access.

Police.uk’s recommendation to reprogramme keys when buying a second-hand car directly supports this point. It treats used-vehicle purchase as a risk point requiring positive action.

The gap is that the recommendation is not normally converted into a formal vehicle-level certificate, auditable record or transferable security-status statement.

4.3 Fleet and pool vehicle use

Fleet vehicles experience repeated Exchanges of Control.

A fleet car, van or operational vehicle may be used by permanent staff, temporary staff, contractors, agency drivers, valeters, repairers, mobile technicians, recovery operators, storage providers or auction handlers. Pool vehicles may pass between users without the same sense of ownership responsibility that applies to a private vehicle.

Commercial vehicles may also carry high-value contents, tools, equipment, stock, documents or customer property. For vans and operational vehicles, unauthorised access may be commercially serious even where the whole vehicle is not stolen.

The VSD risk is not limited to the final user. It accumulates through the vehicle’s operating history.

A fleet operator may know where the vehicle is today, but may not know whether every past key, credential, programming event or temporary access point has been controlled.

This supports a key finding:

Fleet VSD risk is cumulative. The longer and more distributed the vehicle’s access history, the greater the value of a formal control event.

4.4 Rental, lease and subscription vehicles

Rental, lease and subscription vehicles create an even more concentrated version of the same problem.

These vehicles are designed to move between users. A vehicle may pass through many unrelated hands in a short period. Keys may be handled by customers, staff, valeters, collection agents, repairers, parking operators and recovery networks.

Most users will return the vehicle honestly. But the security model should not depend entirely on honesty, memory or assumptions about key handling.

Where a vehicle is later sold into the used market, the next buyer may have very little visibility over its Exchange-of-Control history.

The research question is therefore not whether rental or lease vehicles are inherently unsafe. It is whether the market has a reliable way to restore and evidence security-data confidence before the vehicle moves to the next stage of its lifecycle.

4.5 Repair, recovery and security-related access

Repair and recovery environments create necessary access to vehicles.

A vehicle may be recovered after breakdown, collision, attempted theft or actual theft. It may pass through a recovery agent, repairer, storage yard, insurer-approved network, bodyshop, dealership, locksmith, diagnostic technician or auction facility.

Many of these parties act legitimately and professionally. The issue is that some repair or recovery events involve access to keys, locks, ECUs, diagnostic systems, programming tools or vehicle identity data.

Where that access is security-related, the quality of the record matters.

A receipt for work may show that a key was supplied or a lock was repaired. It may not show the vehicle’s active credential state after completion. It may not show whether missing keys were deleted. It may not show whether the operator was security-vetted. It may not be useful to a future insurer, buyer or fleet manager.

This creates a distinction between ordinary repair evidence and VSD control evidence.

A repair invoice proves that work was sold. A VSD control record should prove what security exposure was assessed, what access was renewed or revoked, and what active state existed after the event.

4.6 Stolen and recovered vehicles

Stolen and recovered vehicles are one of the highest-value use cases for VSD control.

A recovered vehicle may be physically repaired, cleaned, inspected and returned to use. But if the vehicle was accessed or started through electronic compromise, retained credentials, key emulation, diagnostic abuse or unknown methods, physical recovery does not necessarily restore the owner’s security position.

The owner may regain the vehicle but not regain confidence.

The insurer may settle repair costs but still lack certainty about residual access risk.

A future buyer may see a repaired vehicle but not know whether its security-data environment was renewed.

This is the precise point at which a control mechanism becomes most defensible. If a vehicle has suffered actual theft, attempted theft, key loss or suspected electronic compromise, there should be a defined method to assess and, where possible, renew the security state.

The central control question is:

Can the vehicle be returned to a known security-data state, and can that state be evidenced?

4.7 Exchange-of-Control risk matrix

4.8 Research finding

Exchange-of-Control risk shows why vehicle security data cannot be treated as a one-time manufacturer issue.

A vehicle’s security status changes over time. It is affected by sale, use, loss, repair, theft, recovery and access history. The more times control changes, the more uncertainty may accumulate.

The correct response is not to describe all used, fleet, rental or recovered vehicles as unsafe. That would be too broad.

The correct response is to recognise that these vehicles pass through identifiable risk points where a proportionate control event would be valuable.

Vehicle Security Data risk is therefore a lifecycle risk. It should be controlled at lifecycle points.

Section 05

Current Market Responses

The current vehicle-security environment is not empty. There are multiple responses already in place across manufacturers, police, insurers, regulators, vehicle-security researchers, repair networks and aftermarket security providers.

Those responses are important. They reduce risk, improve design, inform consumers, support enforcement and help insurers manage loss exposure.

However, they do not all control the same problem.

Most existing responses are directed at one of five things:

1. preventing theft before it occurs; 2. improving vehicle design; 3. restricting access to security-related repair information; 4. prosecuting or disrupting criminal activity; 5. handling insurance or recovery after loss.

Those are necessary responses, but they do not consistently answer the vehicle-level VSD question:

Has the vehicle’s exposed or suspected-exposed security data been renewed, revoked, evidenced and controlled at a defined point in time?

5.1 Manufacturer and vehicle-design controls

Manufacturers are the first line of vehicle-security design. They create the locks, keys, immobilisers, software, electronic control units, keyless entry systems and anti-theft functions that protect vehicles at the point of manufacture.

The historic evidence shows that manufacturer-level security improvements can have major effects. The Home Office’s 2016 research on vehicle security and vehicle crime examined the role of systematic security improvements, including steering column locks and electronic immobilisers, in reducing criminal opportunity.

This remains an important lesson. Product-level security matters.

However, product design cannot control every later lifecycle event. A manufacturer can design a secure immobiliser, but cannot fully control whether a key is later lost, copied, retained, cloned, misused, emulated or left active after a vehicle is sold, leased, recovered or repaired.

Manufacturers can improve new vehicles. They cannot, on their own, certify every used vehicle’s current security-data status after years of ownership changes, repairs, theft attempts, fleet use or key events.

This creates the first control gap:

Manufacturer security design protects the vehicle as built, but does not necessarily provide a market-wide control record for the vehicle as later used, transferred, compromised or recovered.

5.2 Vehicle cybersecurity and type-approval controls

Vehicle cybersecurity has also become more formalised. UK government vehicle cyber-security principles state that security risks should be assessed and managed appropriately, including supply-chain risks, and that organisations need product aftercare and incident response to keep systems secure over their lifetime.

This is relevant because it shows that vehicle security is already treated as a lifecycle issue in connected and automated vehicle contexts. It is not enough to design security once and assume the system remains secure indefinitely.

However, this kind of vehicle cybersecurity guidance is mainly directed at manufacturers, suppliers and system designers. It is not the same as a practical used-vehicle control system for ordinary owners, buyers, insurers or fleet managers.

The research implication is:

Vehicle cybersecurity frameworks recognise lifecycle security, but the market still lacks a simple vehicle-level process for confirming whether security-data exposure has been controlled after common events such as used sale, key loss, theft recovery or fleet handover.

5.3 Security-related repair information access controls

SERMI is a significant development because it demonstrates that access to security-related vehicle information is sensitive enough to require authorisation.

SERMI UK states that the scheme was created to allow independent operators to access security-related vehicle information, and that it aims to approve and authorise independent garages and service providers to have manufacturer-level access for processes such as programming keys and unlocking immobilisers.

This supports a central research finding.

If programming keys and unlocking immobilisers require controlled authorisation, then vehicle security data is not merely ordinary repair information. It is a sensitive access environment.

SERMI helps address one side of the problem: who is allowed to access manufacturer security-related repair information through legitimate channels.

It does not fully answer a different question:

After a vehicle’s security data has been exposed, accessed, renewed or programmed, what vehicle-level evidence exists for the owner, buyer, insurer or future keeper?

That distinction matters.

An authorised access route may help control the operator. A VSD control framework would help control the vehicle’s security-data status after the event.

5.4 Police and public guidance

Police guidance is an important current response. Police.uk advises vehicle owners to take practical steps such as keeping keyless-entry keys away from the vehicle, using signal-blocking pouches, checking whether pouches still work, reprogramming keys when buying a second-hand car, turning off wireless fob signals where possible, and considering additional physical security.

This guidance is useful and practical. It recognises several core VSD risk points:

• keyless-entry signals can be exploited;
• second-hand vehicles may carry security uncertainty;
• reprogramming can be a meaningful control step;
• physical deterrents may reduce theft opportunity.

However, police guidance is advisory. It does not create a formal control event. It does not generate a certificate. It does not create a transferable record. It does not confirm the number of active keys or credentials after reprogramming. It does not necessarily link the vehicle, operator, work performed and security outcome into an auditable data trail.

The police can advise the owner to act. The owner still needs a practical and evidential mechanism for proving that action has been taken.

This creates the next control gap:

Police advice identifies the risk and recommends mitigation, but does not itself create a formal vehicle-level VSD control record.

5.5 Criminal-tool enforcement

The UK government has moved toward specific action against electronic vehicle-theft devices. The Home Office has stated that electronic devices are used by criminals in 40% of vehicle thefts in England and Wales, and that organised criminals try to overcome security measures in even the latest vehicles by exploiting vulnerabilities and new technologies.

This policy direction is important because it confirms that electronic theft capability has become a recognised enforcement problem.

However, enforcement against tools is not the same as control of an individual vehicle’s security-data state.

A tool ban may reduce availability. It may make possession, import, manufacture or distribution riskier. It may assist police in disrupting criminal networks. Those are valuable outcomes.

But it does not answer the post-exposure question:

If a vehicle has already been accessed, stolen, recovered, programmed, cloned or subjected to attempted theft, has the vehicle’s security-data exposure been resolved?

Tool enforcement controls the criminal environment. It does not automatically renew the vehicle.

5.6 Insurance response

Insurers respond to vehicle-security risk through underwriting, claims handling, repair networks, fraud investigation, approved suppliers, security-device requirements and pricing.

Insurance is therefore an important stakeholder environment for any VSD control model.

However, insurance generally responds to risk rather than directly controlling the security data itself. An insurer may ask whether keys were present, whether a tracker was fitted, whether theft was reported, whether security devices were used, or whether circumstances suggest fraud or negligence.

Those questions may be necessary, but they are imperfect proxies for VSD control.

A policyholder may possess two keys while another active credential still exists. A used vehicle may have been bought honestly with one key. A recovered vehicle may be repaired without its security-data state being fully renewed. A fleet vehicle may have key logs but no credential audit.

This creates an evidence problem for both sides.

Policyholders may struggle to prove that they controlled the risk. Insurers may struggle to distinguish genuine theft from negligence, fraud or unresolved security exposure.

A formal VSD control record would not remove all claims disputes, but it could improve the evidential position by answering a narrower question:

At a known point in time, what security-data control work was performed, by whom, and what was the known active security state afterwards?

5.7 Aftermarket deterrents and security products

The aftermarket provides many useful products and services: steering locks, wheel clamps, trackers, immobilisers, alarms, OBD port protection, Faraday pouches, ghost immobilisers, dash cameras, parking security and physical storage controls.

These products can materially reduce theft risk. In some cases, they may be essential for high-risk vehicles or high-risk locations.

However, most aftermarket deterrents do not resolve historic VSD exposure.

A steering lock may deter theft, but it does not delete a missing digital key. A tracker may help recover a stolen vehicle, but it does not prove that no third party retains active access. A Faraday pouch may reduce relay risk, but it does not address a previous owner’s retained key. An aftermarket immobiliser may add protection, but it may not certify the original vehicle-security-data state.

This distinction is central.

A deterrent adds friction. A VSD control event should reduce uncertainty.

Both can be valuable, but they are not the same.

5.8 Current response vs control gap matrix

5.9 Research finding

The current market response is fragmented, not absent.

Each stakeholder controls part of the problem:

• manufacturers control design;
• SERMI controls legitimate access to security-related repair information;
• police control prevention guidance and enforcement;
• government controls legislation;
• insurers control pricing and claims response;
• aftermarket providers control additional deterrence;
• repairers control specific work tasks.

But no single response consistently creates a vehicle-level answer to the VSD control question.

The missing layer is not another general theft warning. The missing layer is a repeatable, evidential control event for vehicle security data exposure.

Section 06

The Core Control Failure

The core control failure is that Vehicle Security Data is treated as sensitive when accessed, but not consistently controlled after exposure.

The market already behaves as though VSD matters. Manufacturers protect it. SERMI authorises access to it. Police warn consumers about it. Government legislates against electronic devices used to exploit it. Insurers price and investigate losses connected to it.

Yet the ordinary vehicle lifecycle still lacks a consistent control mechanism that answers:

Who can access this vehicle now?

That is the central question.

It cannot always be answered by looking at the keys. It cannot always be answered by looking at the vehicle. It cannot always be answered by checking whether the vehicle starts. It cannot always be answered by reviewing a repair invoice.

Vehicle Security Data can exist outside the vehicle owner’s field of view.

6.1 Why manufacturers cannot fully contain the risk

Manufacturers can design stronger security systems, improve keyless technology, patch software, control dealer access and comply with cybersecurity expectations.

But vehicles leave the manufacturer environment.

They are sold, leased, shared, rented, repaired, recovered, modified, stolen, exported, imported, broken for parts and resold. Keys are lost. Fobs are replaced. ECUs are programmed. Locks are decoded. Aftermarket tools are used. Criminals adapt.

The manufacturer remains important, but the manufacturer cannot be the only control layer.

A manufacturer may know how the vehicle was built, but not every downstream exposure event across the vehicle’s working life.

This is why VSD risk should not be framed only as a manufacturer-defect problem. It is also a lifecycle-control problem.

6.2 Why police and international enforcement cannot fully contain the risk

Police and international enforcement bodies can target organised criminals, recover stolen vehicles, disrupt networks, investigate offences, seize equipment and support public prevention campaigns.

That work is essential.

But enforcement operates within practical limits. Criminal tools move quickly. Knowledge spreads. Devices can be imported, adapted or replaced. Vehicles can be stolen in minutes. Stolen vehicles can be moved across regions, dismantled, cloned or exported.

The Home Office’s focus on banning electronic theft devices shows that enforcement is increasingly concerned with the capability market itself, not only with individual theft events.

However, even successful enforcement does not certify an individual vehicle’s security-data status after an exposure event.

Police may recover a stolen vehicle. They may arrest an offender. They may warn the public. But they do not ordinarily issue a vehicle-level VSD certificate confirming that the vehicle’s active security credentials have been renewed or controlled.

That is not a criticism of policing. It is a recognition that policing and VSD control are different functions.

6.3 Why insurers cannot fully contain the risk

Insurers can price risk, incentivise deterrents, require trackers, investigate claims, approve repair networks and refuse fraudulent or unsupported claims.

However, insurers are often dealing with evidence after the event.

A theft has occurred. A key is missing. A vehicle has been recovered. A policyholder reports circumstances. A claims handler must assess credibility, policy compliance and causation.

In that environment, key count is useful but incomplete.

The existence of two keys does not prove that no other active credential exists. The absence of two keys does not prove fraud or negligence. A replacement-key invoice does not necessarily prove that old keys were deleted. A recovered vehicle does not necessarily prove that security exposure was neutralised.

Insurers therefore face two problems at the same time:

1. genuine policyholders may struggle to prove they controlled VSD risk; 2. insurers may struggle to detect unresolved exposure, negligence or fraud.

A formal VSD control event would not replace investigation, but it would improve the evidence base.

It would convert part of the claim from narrative uncertainty into a recorded control fact.

6.4 Why consumers cannot fully contain the risk

Consumers are asked to protect their keys, use pouches, park securely, check locks, use deterrents and reprogramme keys after second-hand purchase.

That advice is reasonable.

But a consumer cannot audit the whole VSD ecosystem.

A used-vehicle buyer cannot easily know whether a previous owner retained a key. A fleet buyer cannot easily know how many temporary drivers handled the vehicle. A recovered-vehicle owner cannot necessarily know how the vehicle was stolen. A private owner cannot inspect whether a digital credential remains active without specialist support.

This creates an unfair information burden.

The least technically informed party often carries the most practical risk.

The consumer is expected to protect something they cannot fully see.

6.5 Why repair evidence is not enough

The market already produces repair evidence: invoices, job sheets, dealer records, service history, parts receipts, diagnostic reports and insurance repair files.

These records are useful, but they are not always VSD control records.

A repair invoice may show that a key was supplied. It may not show whether old keys were deleted. A locksmith receipt may show access was restored. It may not show the number of active keys remaining in the vehicle memory. A recovery record may show a vehicle was returned. It may not show whether the theft method left residual exposure.

The difference is important:

The problem is not that repair records are useless. The problem is that they were not designed to answer the security-data proprietorship question.

6.6 The core control failure stated plainly

The core failure is this:

Vehicle Security Data can be copied, retained, exposed or exploited, but the market does not yet have a consistent method for restoring and evidencing control after that happens.

This creates uncertainty for:

• private owners;
• used-vehicle buyers;
• dealers and marketplaces;
• fleet operators;
• rental companies;
• insurers;
• claims handlers;
• manufacturers;
• police and public authorities;
• legitimate vehicle security operators.

Each stakeholder can see part of the problem. None can fully contain it alone.

The realistic objective is therefore not total prevention.

The realistic objective is controlled status.

A better environment would not claim that a vehicle can never be stolen. It would claim something narrower, stronger and more defensible:

At a defined point in time, after a defined risk trigger, the vehicle’s relevant security-data exposure was assessed, renewed, revoked or controlled by a competent operator, and the known outcome was evidenced.

6.7 Research finding

The market does not need to eliminate every criminal method before improving VSD control.

It needs a practical, repeatable and evidential control layer that sits between the current fragmented responses.

The research finding is therefore:

Vehicle Security Data should be managed like other serious lifecycle risks: not by assuming perfect prevention, but by creating defined control events, competent operators, documented outcomes, transferable evidence and clear limitation statements.

Section 07

Problem, Risk and Outcome Matrix

The preceding sections establish that Vehicle Security Data is a distinct lifecycle risk class. It can be copied, retained, transferred, inferred, exposed or exploited without leaving the kind of visible evidence that ordinary vehicle-condition risks usually create.

The purpose of this section is to convert that issue into a practical problem-risk-outcome matrix.

This is important because the argument for a Vehicle Security Data control environment should not depend on a general fear of vehicle theft. It should depend on specific problems, specific exposed parties and specific control outcomes.

The relevant question is:

What problem is created by uncertain Vehicle Security Data, who is exposed by that problem, and what would a better control outcome look like?

7.1 Problem-risk-outcome matrix

7.2 The recurring pattern

The matrix shows a repeating pattern.

In each case, the issue is not simply that a vehicle might be stolen. The issue is that a party is being asked to rely on incomplete evidence of control.

The private owner relies on physical possession.

The used buyer relies on the seller’s description and the keys supplied.

The insurer relies on policyholder statements, key possession and circumstantial evidence.

The fleet operator relies on internal logs and key-return processes.

The dealer relies on prior history and normal preparation.

The police can respond to crime, but do not usually verify the technical security-data state of the vehicle after recovery.

This produces the same control gap across different scenarios:

The market can often identify that a risk exists, but cannot consistently prove that the risk has been technically controlled.

7.3 Risk severity is not uniform

Not every VSD issue carries the same level of risk.

A missing mechanical key for an older vehicle may create unauthorised access risk but not full theft risk. A missing digital key for a keyless-start vehicle may create access and theft risk. A stolen and recovered vehicle may require a deeper security assessment than a vehicle sold with two keys and no adverse history. A rental vehicle returning after ordinary use may require a different control threshold from a vehicle recovered after theft.

A credible model should therefore avoid treating every vehicle in the same way.

Instead, it should classify exposure by:

• the type of VSD involved;
• whether the exposure is known, suspected or merely possible;
• whether the vehicle can be accessed, started or both;
• the number of parties who may have had control;
• the value and use case of the vehicle;
• the seriousness of the trigger event;
• whether the vehicle is moving to a new relying party.

This supports a risk-based approach rather than a blanket approach.

7.4 Trigger-based control

The strongest control model is trigger-based.

A trigger is a defined event that makes VSD control appropriate.

Examples include:

The control event should be proportionate to the trigger.

The paper should not imply that every vehicle needs full mechanical and digital renewal at every transfer. The better argument is that a formal framework should define which control is appropriate at which risk point.

7.5 Required outcome categories

A Vehicle Security Data control event may produce different types of outcome.

The last category is important.

A credible control framework must be honest about technical limitations. It should not invent certainty where certainty is not available. A statement that a condition could not be verified may still be valuable because it prevents false assurance.

7.6 Research finding

The problem-risk-outcome analysis supports one clear finding:

Vehicle Security Data risk does not require a single universal repair. It requires a defined control environment capable of matching the trigger, VSD type and stakeholder need to an appropriate evidence-backed outcome.

This moves the paper away from a narrow “anti-theft product” argument and toward a stronger lifecycle-risk-control argument.

Section 08

Parameters for a Vehicle Security Data Control Environment

A Vehicle Security Data control environment should not claim to solve all vehicle theft. It should not claim that any vehicle can be made permanently immune from compromise. It should not imply that manufacturers, police, insurers or consumers can eliminate every threat if they simply follow one process.

The more defensible objective is narrower:

A vehicle should be capable of being brought into a known, evidenced and controlled security-data state at defined points in its lifecycle.

That is the model truth.

A vehicle can be controlled at a point in time. It cannot be guaranteed forever.

8.1 Defined risk triggers

A credible control environment should begin with defined risk triggers.

Without defined triggers, the process becomes vague. Owners may not know when action is appropriate. Insurers may not know when evidence should be requested. Fleet operators may not know when a control event should be mandatory. Dealers may not know when a vehicle should be marketed with additional security-status evidence.

Defined triggers create a common language.

Minimum trigger categories should include:

• used vehicle purchase;
• sale or remarketing;
• missing key;
• stolen key;
• theft or attempted theft;
• vehicle break-in;
• theft recovery;
• security-related repair or programming;
• fleet handover;
• employee or contractor exit;
• rental or subscription return after high-risk use;
• insurer or finance-provider request;
• owner concern or suspected compromise.

The purpose of the trigger is not to prove compromise. The purpose is to identify when uncertainty becomes sufficient to justify control.

8.2 Vehicle-level control

The control environment must operate at vehicle level.

This is important because VSD risk follows the vehicle. It does not sit only with the owner, seller, insurer, manufacturer or repairer.

A used-vehicle buyer needs to know the security status of the specific vehicle being purchased. A fleet manager needs to know the status of the specific vehicle returning from use. An insurer needs to know the status of the specific insured vehicle. A future buyer may need to rely on a record created before they owned it.

A general statement that a repairer is competent is useful but incomplete.

A general statement that a manufacturer has strong security is useful but incomplete.

A general statement that a policyholder has two keys is useful but incomplete.

The key question is vehicle-specific:

What is the known security-data status of this vehicle after this control event?

8.3 Mechanical and digital scope

A credible framework must distinguish between Mechanical VSD and Digital VSD.

Mechanical VSD controls may include:

• lock replacement;
• lock rebuild;
• key blade replacement;
• key-code renewal;
• deletion of reliance on prior mechanical key profile where possible;
• recording of mechanical renewal work.

Digital VSD controls may include:

• active key interrogation;
• key deletion;
• immobiliser credential renewal;
• new key programming;
• lost or stolen key disablement;
• ECU or module security-related work;
• remote locking or keyless access review;
• recording of active key or credential count where technically available.

The two categories should not be blurred.

A mechanical lock change may not remove a digital start credential. A digital key deletion may not stop a retained mechanical blade from opening a door. A proper framework needs to state which category was assessed and which category was controlled.

8.4 Renewal, revocation or evidence outcome

The control environment should produce one or more clear outcomes.

It is not enough to say “vehicle checked” or “key programmed”.

The outcome should state whether the relevant VSD was:

• assessed;
• renewed;
• revoked;
• superseded;
• recorded;
• certified;
• or unable to be verified.

This creates honesty and utility.

A buyer does not only need to know that a vehicle had a key cut. They need to know whether prior access remains possible.

An insurer does not only need to know that a new fob was supplied. It may need to know whether the stolen fob was deleted.

A fleet operator does not only need to know that keys were returned. It may need to know whether the active credential environment was controlled after repeated handovers.

8.5 Competent and traceable operator requirement

Vehicle Security Data control should be performed by competent and traceable operators.

This is essential because the control event itself involves access to sensitive systems. A poorly governed operator can become the next risk point.

A credible environment should therefore include:

• operator identity;
• business identity;
• authorisation or approval status where relevant;
• technical competence;
• appropriate tools and procedures;
• auditability;
• complaints or accountability route;
• record of work performed;
• date and time of work;
• vehicle identity verification.

SERMI-style access-control logic supports this principle. Where operators access security-related repair information, the market already recognises the need for authorisation and control. ([sermi.co.uk](https://sermi.co.uk/?utm_source=chatgpt.com))

A VSD control framework should extend the same principle to the outcome relied on by the vehicle owner or market participant.

8.6 Evidence record

Evidence is central.

Without evidence, the control event is useful only to the person who remembers it. With evidence, the control event can support future reliance.

A VSD control record should ideally include:

• vehicle registration mark;
• vehicle identification number;
• date and time of control event;
• risk trigger;
• VSD category assessed;
• operator identity;
• work performed;
• active key or credential count where technically available;
• outcome status;
• limitations;
• certificate or reference number;
• relying party, where relevant.

The record should be understandable to non-technical parties while still being specific enough to matter.

A good certificate should not be a dense diagnostic printout. It should translate the technical work into a clear risk-control outcome.

8.7 Time-stamped status

A VSD control record should be time-stamped and limited.

This is because security status can change after the control event.

A vehicle may be controlled today and compromised tomorrow. A key may be lost next week. A new user may gain access next month. A criminal may exploit a new method later.

Therefore, a credible statement should avoid promising permanent security.

It should say, in effect:

At the date and time of the control event, the identified VSD exposure was assessed and controlled in the manner stated.

That limitation does not weaken the model. It makes the model credible.

It is similar to other risk-control records. An MOT does not prove a vehicle will remain roadworthy forever. A gas safety certificate does not prove no future fault can occur. A cyber audit does not prove a system can never be compromised. A VSD control record should work in the same way: evidence of status at a defined point in time.

8.8 Transferable reliance

The control record should be capable of being relied on by more than one party.

The original owner may need it after buying a used car. A future buyer may need it when reviewing vehicle history. An insurer may need it at policy inception or claim stage. A fleet operator may need it for internal governance. A dealer may need it to support sale preparation. A finance provider may need it for asset-risk management.

Transferable reliance is where the framework becomes more valuable than a repair receipt.

A repair receipt proves a transaction.

A transferable VSD control record supports a continuing risk history.

8.9 Market compatibility

A credible solution must fit the existing market.

It should not require every vehicle owner to use a single supplier. It should not require manufacturers to redesign all systems before the model can operate. It should not require police to certify technical repair outcomes. It should not require insurers to change all claims processes before any value exists.

Instead, it should sit alongside existing workflows:

• locksmith and vehicle-security work;
• dealer preparation;
• used-vehicle sales;
• fleet return processes;
• insurer repair and recovery networks;
• post-theft repair;
• key-loss response;
• vehicle history and certification services.

The strongest version of the model is infrastructure-like. It defines the control process, evidence standard and outcome language, while allowing multiple competent operators and stakeholders to participate.

8.10 Clear limitation statement

A VSD control environment must include clear limitations.

It should not claim:

• to prevent all theft;
• to eliminate all criminal methods;
• to guarantee permanent security;
• to replace policing;
• to replace manufacturer security;
• to replace insurance investigation;
• to prove no future compromise can occur.

It should claim something narrower:

It provides a formal method for assessing, renewing, revoking, recording and certifying identified Vehicle Security Data exposure at a defined point in time.

That is enough.

The value is not that it makes the vehicle invulnerable. The value is that it converts hidden uncertainty into an evidenced control event.

8.11 Solution success criteria matrix

8.12 Research finding

The correct solution parameters are now clear.

A better VSD environment should not attempt to control every criminal, every tool, every manufacturer system or every future theft method.

It should control the vehicle’s security-data status after defined risk events.

The research finding is therefore:

A credible Vehicle Security Data control environment should create repeatable, vehicle-level, time-stamped control events that assess, renew, revoke, record and certify the known security-data state of a vehicle, while clearly stating the scope and limitations of that control.

Section 09

Vehicle Security Data Renewal and Certification Model

The preceding sections establish the core problem and the necessary solution parameters.

Vehicle Security Data is transient, transferable and difficult to audit. It can be copied, retained, exposed or exploited without leaving visible evidence. Existing market responses are useful but fragmented. Manufacturers, police, insurers, consumers and repairers each control part of the issue, but no single party can contain the whole lifecycle risk.

The appropriate response is therefore a defined renewal and certification model.

The model should not claim that a vehicle can be made permanently immune from theft. It should not claim that all criminal methods can be eliminated. It should not claim that every future access risk can be predicted.

The model truth is narrower and stronger:

A vehicle can be made controlled at a point in time. It cannot be made permanently immune.

That is the basis for a Vehicle Security Data renewal and certification model.

9.1 Purpose of the model

The purpose of a VSD renewal and certification model is to create a formal control event after a defined risk trigger.

That control event should answer:

• what risk triggered the assessment;
• which vehicle was assessed;
• which category of VSD was in scope;
• who performed the work;
• what was assessed, renewed, revoked or recorded;
• what active access credentials were known after completion;
• what could not be verified;
• what evidence was created.

This does not replace manufacturer security, police enforcement, insurer investigation or consumer precautions. It sits between them.

It converts hidden security-data uncertainty into a practical control record.

9.2 Model stages

A VSD renewal and certification model should operate through a clear sequence.

This sequence is deliberately practical. It does not depend on the whole vehicle-crime ecosystem changing first. It starts with the vehicle and creates a control event around that vehicle.

9.3 Mechanical VSD renewal

Mechanical VSD renewal concerns physical access data.

It may be relevant where:

• a mechanical key has been lost or stolen;
• a vehicle has been sold with uncertain key history;
• a key blade does not match the lock;
• a previous owner or third party may retain a key;
• a vehicle has been broken into;
• lock access has been compromised;
• a commercial vehicle contains high-value goods or tools.

Mechanical renewal may include:

• replacing lock barrels;
• rebuilding existing locks;
• issuing new key blades;
• changing the key profile;
• recording the new mechanical access state;
• confirming which mechanical keys are supplied after completion.

The purpose is to reduce the risk that a previous or unknown party can use old mechanical access data to enter the vehicle.

Mechanical VSD renewal is especially relevant where unauthorised access itself is serious, even if the vehicle cannot be started mechanically. This may include vans, service vehicles, vehicles carrying tools, delivery vehicles, vehicles containing documents, and vehicles used in sensitive operational environments.

9.4 Digital VSD renewal

Digital VSD renewal concerns electronic access, authorisation and start capability.

It may be relevant where:

• a digital key or fob has been lost or stolen;
• a vehicle has been bought used with incomplete key history;
• a vehicle has been stolen and recovered;
• there has been an attempted theft;
• a key has been cloned or suspected to be cloned;
• additional keys may have been programmed;
• a vehicle has passed through repeated fleet, rental or repair access;
• an insurer or owner requires confirmation of active keys.

Digital renewal may include:

• interrogating the vehicle’s recognised keys or credentials where technically possible;
• deleting missing or unauthorised keys;
• programming new authorised keys;
• disabling stolen credentials;
• replacing or reprogramming security-related modules where required;
• confirming the known number of active keys or credentials after completion;
• recording limitations where the vehicle platform does not support full confirmation.

Digital VSD renewal is often the higher-priority control because it may affect both access and theft.

A vehicle with compromised Digital VSD may be capable of being unlocked and started by someone other than the current keeper. For keyless-entry or push-start vehicles, this may occur without traditional forced entry.

The purpose of digital renewal is not simply to add a new key. It is to restore confidence that missing, retained or compromised credentials have been disabled, superseded or recorded as far as the vehicle platform allows.

9.5 Combined VSD renewal

Some events require combined mechanical and digital control.

Examples include:

• stolen keys where the key includes both blade and transponder;
• theft recovery where the access method is unknown;
• used vehicle purchase with incomplete or suspicious key history;
• break-in followed by missing key or document theft;
• commercial vehicle misuse or employee access concern;
• high-value or high-risk vehicle transfer.

Combined renewal matters because mechanical and digital VSD solve different parts of the access problem.

Deleting a digital key may stop the vehicle being started, but may not stop a retained blade opening a door.

Replacing a lock may stop mechanical entry, but may not stop a retained digital key from unlocking or starting the vehicle.

A proper control environment should therefore state whether the event was mechanical, digital or combined.

9.6 Certification

Certification is the feature that turns a repair event into a risk-control event.

Without certification, the work may still be technically useful, but the evidence value is limited.

A VSD control certificate should ideally state:

• certificate reference;
• vehicle registration mark;
• vehicle identification number;
• date and time of control event;
• trigger event;
• requesting party or relying party;
• operator identity;
• operator approval or competence status where relevant;
• VSD category in scope;
• work performed;
• known active key or credential count after completion where technically available;
• whether old credentials were removed, disabled, superseded or not verifiable;
• limitations;
• declaration of status at the point in time.

The certificate should not overclaim.

It should not say:

“This vehicle cannot be stolen.”

It should say something closer to:

“At the date and time of this control event, the identified Vehicle Security Data exposure was assessed and the stated mechanical and/or digital security-data controls were completed. The known active access state after completion is recorded below, subject to the limitations stated.”

That wording is less dramatic but more defensible.

9.7 Data record

The certification layer should ideally be supported by a data record.

This record may support:

• future owner reliance;
• dealer preparation records;
• fleet governance;
• insurer underwriting;
• claims evidence;
• post-theft repair files;
• vehicle history review;
• operator audit;
• dispute resolution.

The data record does not need to disclose sensitive technical details that would create further security risk. It should record enough to prove that the control event occurred and what outcome was declared.

There is a balance to strike.

Too little data makes the record useless. Too much data may create a new security exposure.

The appropriate model is therefore a controlled evidence record, not an open technical security file.

9.8 Limitation handling

Limitation handling is central to the credibility of the model.

Some vehicles may not allow all active credentials to be read. Some systems may not provide useful key counts. Some platforms may require manufacturer-level access. Some older vehicles may have limited digital architecture. Some theft methods may leave no diagnostic trace. Some repair circumstances may prevent full assessment.

A credible VSD framework should record these limitations rather than hide them.

Possible limitation categories include:

• active key count not technically available;
• mechanical access not assessed;
• digital access not assessed;
• vehicle system does not support deletion of specific credential;
• manufacturer access required;
• evidence incomplete;
• theft method unknown;
• prior repair history unavailable;
• operator unable to verify specified item.

This helps prevent false assurance.

A certificate that says “unable to verify” is still valuable where it is honest. It tells a relying party that risk remains uncertain rather than pretending it has been removed.

9.9 Model truth

The model truth should sit at the centre of the paper:

Controlled at a point in time, not permanently immune.

This gives the framework its proper shape.

The model does not promise perfect security. It creates a point-in-time control event.

That is how many risk-control environments work.

An MOT does not guarantee a vehicle will remain roadworthy forever. A gas safety certificate does not guarantee no later fault will arise. A cyber audit does not guarantee no future breach will occur. A financial audit does not guarantee no future fraud will happen.

Those records still matter because they create evidence of assessment, process and status at a defined point.

A VSD renewal and certification record should do the same.

9.10 Research finding

A Vehicle Security Data renewal and certification model is justified where three conditions exist:

1. the relevant security data is capable of being copied, retained or exposed; 2. the current keeper or relying party cannot independently verify who holds usable access; 3. a technical control event can reduce uncertainty and produce evidence.

Where those conditions exist, the appropriate response is not merely advice, deterrence or enforcement.

The appropriate response is a formal control event.

The research finding is that VSD renewal and certification should be understood as a post-exposure control mechanism: a way of restoring and evidencing security-data confidence after defined lifecycle risk events.

Section 10

Stakeholder Outcomes

A Vehicle Security Data control environment creates value because different stakeholders currently experience the same underlying problem in different ways.

The private owner experiences uncertainty.

The used buyer experiences information asymmetry.

The dealer experiences preparation and disclosure risk.

The fleet operator experiences repeated access and key-control risk.

The insurer experiences evidence and fraud-risk uncertainty.

The manufacturer experiences downstream security exposure beyond its direct control.

The police experience crime, recovery and enforcement demand.

The vehicle security operator experiences a market where sensitive work may be performed without consistent evidence standards.

A better control environment does not remove all risk for any of these stakeholders. It gives each of them a clearer way to identify, reduce and evidence a defined part of the risk.

10.1 Private vehicle owners

Private owners are the most exposed to information asymmetry.

A private owner may buy a used vehicle without knowing whether previous owners, garages, employees, family members, criminals or third parties have retained usable access. The owner may lose a key and replace it without understanding whether the missing key remains active. The owner may recover a stolen vehicle without knowing whether the theft method left residual access risk.

A VSD control event gives the owner a practical route to restore confidence.

Better outcome:

The owner can evidence that a specific VSD concern was assessed and controlled at a defined point in time.

This is particularly useful after:

• used vehicle purchase;
• key loss;
• stolen key;
• break-in;
• theft recovery;
• suspicious access;
• insurance request;
• resale preparation.

10.2 Used vehicle buyers

Used vehicle buyers rely heavily on seller disclosure, visible condition, service history, MOT history, finance checks and key count.

Those checks are useful, but they do not fully answer the security-data question.

A used vehicle can be mechanically sound and financially clear while still carrying unresolved access uncertainty.

A VSD control record could give buyers an additional layer of confidence, particularly for higher-value vehicles, keyless vehicles, stolen-recovered vehicles, ex-rental vehicles, ex-fleet vehicles and vehicles sold with limited key history.

Better outcome:

The buyer can assess vehicle security status using evidence rather than relying only on key count and seller assurance.

10.3 Used vehicle dealers and marketplaces

Dealers and marketplaces operate in a trust environment.

They already understand the value of provenance, inspection, preparation, finance checks, HPI-style data, MOT history and service records.

Security-data status could become another form of vehicle preparation evidence.

A dealer may not be responsible for every historic exposure event, but can improve the vehicle’s market position by commissioning a control event before sale or by disclosing whether no such control has been performed.

Better outcome:

Dealers and marketplaces can distinguish vehicles with evidenced VSD control from vehicles with unknown security-data status.

This could be particularly relevant for:

• one-key vehicles;
• high-theft models;
• premium vehicles;
• keyless vehicles;
• ex-fleet vehicles;
• ex-rental vehicles;
• theft-recovered vehicles;
• vehicles with replacement keys.

10.4 Fleet operators

Fleet operators face repeated and cumulative access risk.

Vehicles may be used by employees, contractors, temporary workers, agency drivers, valeters, repairers, recovery agents and delivery personnel. Keys may be held, returned, copied, lost or mishandled. Digital credentials may remain active after user changes.

Fleet key management is therefore more than a convenience issue. It is an asset-control and security-governance issue.

A VSD control framework could support fleet operators by creating defined control events after high-risk handovers.

Better outcome:

Fleet operators can move from informal key control to evidenced vehicle-level security-data control.

Relevant triggers may include:

• employee exit;
• lost key;
• suspected misuse;
• vehicle reassignment;
• return from long-term user;
• return from rental or contractor use;
• theft recovery;
• sale or disposal.

10.5 Rental, leasing and subscription operators

Rental, leasing and subscription operators manage vehicles that are designed to move between users.

The more often a vehicle changes hands, the more difficult it becomes to maintain certainty over access history.

A VSD control model does not require full renewal after every ordinary rental. That would be impractical.

But it can define risk thresholds. For example, control may be appropriate after missing keys, suspicious use, theft, attempted theft, non-return, customer dispute, high-risk recovery or before disposal into the used market.

Better outcome:

Operators can apply proportionate VSD control at defined risk points rather than relying only on general return checks.

10.6 Insurers and claims handlers

Insurers need evidence.

At policy inception, insurers may want to know whether a vehicle has additional security devices, whether it has keyless entry, where it is kept, and whether it has theft history.

At claim stage, insurers may need to assess whether theft occurred, whether keys were lost, whether the policyholder took reasonable care, whether fraud is suspected, and whether repair or settlement is appropriate.

A VSD control record could support both underwriting and claims.

It could show that:

• a missing key was deleted;
• a stolen key was disabled;
• a recovered vehicle was security-assessed;
• active key count was recorded;
• an owner took a control step after buying a used vehicle;
• a fleet operator controlled access after an employee exit;
• a repairer performed security-related work to a defined standard.

Better outcome:

Insurers gain a stronger evidence layer for vehicle security-data status, reducing reliance on incomplete key-count proxies and retrospective narratives.

This does not remove fraud investigation. It improves the quality of relevant evidence.

10.7 Police and public authorities

Police and public authorities are not expected to certify every vehicle’s security state.

Their role is crime prevention, investigation, enforcement, public guidance and disruption of criminal networks.

A VSD control environment could support that role indirectly. If more vehicles have clearer post-risk security records, there may be better distinction between ordinary vehicle theft, unresolved security exposure, repeat compromise, suspicious claims and known high-risk patterns.

Better outcome:

Police and public authorities can continue focusing on crime prevention and enforcement while the technical control of individual vehicle security-data exposure is handled through a specialist market mechanism.

This distinction is important. The control model should not place unrealistic technical certification burdens on police forces.

10.8 Manufacturers and dealer networks

Manufacturers are responsible for design and authorised systems, but they cannot fully control every downstream exposure event.

A VSD control environment can support manufacturers by addressing a risk that occurs after the vehicle has entered the wider market.

It can also help distinguish product-security issues from lifecycle-security issues.

If a vehicle is stolen because of an unresolved post-sale key or credential exposure, that is different from a design defect. If a vehicle is compromised through a model-specific electronic attack, that may raise manufacturer-security questions. A better evidence environment helps separate those categories.

Better outcome:

Manufacturers and dealer networks benefit from clearer downstream security-data records without being treated as the sole controller of all lifecycle exposure.

10.9 Vehicle security operators

Vehicle security operators are central to the practical model.

They already perform key replacement, lock work, immobiliser programming, security repair, diagnostic access and related services. However, without a consistent framework, the evidence value of that work may vary widely.

A VSD control environment gives legitimate operators a clearer role.

It distinguishes competent, traceable, evidenced security work from informal or unevidenced access.

Better outcome:

Vehicle security operators can provide recognised VSD control services supported by standardised records, defined outcomes and clearer market trust.

This is also important for protecting the reputation of legitimate operators from the wider uncontrolled tool market.

10.10 Stakeholder outcome matrix

10.11 Research finding

The stakeholder analysis supports the central conclusion of the paper.

Vehicle Security Data uncertainty harms multiple parties, but not in identical ways. The same hidden exposure may create theft risk for the owner, claims uncertainty for the insurer, disclosure risk for the dealer, access-governance risk for the fleet operator and reputational risk for the wider vehicle-security market.

A VSD renewal and certification model creates a common control language across those parties.

The research finding is that a vehicle-level VSD control record would not merely help prevent theft. It would improve evidence, trust, transferability and accountability across the vehicle lifecycle.

Section 11

Overall Findings

This document has examined Vehicle Security Data as a distinct and under-controlled risk class within the vehicle lifecycle.

The research does not suggest that every vehicle is compromised, or that all vehicle theft can be prevented through a single process. It also does not suggest that manufacturers, police, insurers, repairers or vehicle owners are individually responsible for solving the entire problem.

The finding is narrower.

Vehicle Security Data can be copied, retained, accessed, exposed or exploited without leaving visible evidence. Once uncertainty exists, the current vehicle keeper may not be able to determine who else holds usable access, whether old credentials remain active, whether prior access has been revoked, or whether the vehicle has been returned to a known security state.

That creates a market gap.

Current responses are necessary but incomplete. Manufacturer security design, vehicle cybersecurity regulation, SERMI-style access control, police guidance, electronic-device enforcement, insurance claims investigation and aftermarket deterrents each control part of the problem. None of them consistently creates a vehicle-level, transferable and time-stamped record showing that known or suspected VSD exposure has been assessed, renewed, revoked or controlled.

The central conclusion is therefore:

11.1 Finding one: Vehicle Security Data is a distinct risk class

Vehicle Security Data is not merely a key, a lock, a diagnostic code or a manufacturer system.

It is the set of mechanical, digital, electronic or credential-based information that allows a vehicle to be accessed, unlocked, started, programmed or re-authorised.

Its key characteristic is that it can exist outside the visible vehicle.

A vehicle can look secure while security data remains uncontrolled. A current keeper can possess the vehicle while another party retains usable access. A used buyer can receive keys while missing or cloned credentials remain active. A recovered vehicle can be physically repaired while its security-data state remains uncertain.

This makes VSD a distinct risk class.

11.2 Finding two: Key possession is not the same as security-data control

Key count is useful, but incomplete.

A vehicle supplied with two keys may still have historic exposure. A vehicle supplied with one key may not be unsafe if the missing credential has been deleted and evidenced. A stolen key may be harmless if it has been disabled, but highly material if it remains active. A replacement-key invoice may not prove that old access was revoked.

This means the market should avoid treating physical key possession as the only practical proxy for VSD control.

A stronger model requires evidence of active credential status, work performed, operator identity and limitation handling.

11.3 Finding three: Legitimate access controls confirm that VSD is sensitive

The existence of security-related repair access controls is significant.

SERMI-style systems recognise that independent operators require access to security-related vehicle information, but that access must be authorised and governed. That includes processes such as programming keys and unlocking immobilisers.

This validates the underlying risk.

If legitimate access to key programming and immobiliser information requires control, then the vehicle-level outcome after such access also deserves structured evidence.

The gap is not only “who may access security-related data?” It is also “what evidence exists after the vehicle’s security state has been changed or exposed?”

11.4 Finding four: Criminal capability has become tool-enabled and market-enabled

Electronic theft devices, relay methods, signal-jamming, key emulation, CAN-bus compromise, diagnostic abuse and organised theft networks have changed the risk environment.

The Home Office has recognised electronic devices as a material factor in vehicle theft. Police guidance now includes advice on keyless theft, signal-blocking pouches, locking-signal checks and key reprogramming after second-hand purchase. Independent security research has also identified organised criminal exploitation of modern theft methods.

This means VSD risk is no longer limited to obvious key theft or forced entry.

The capability to access, replicate or bypass vehicle-security systems may exist outside the owner’s view and outside traditional repair channels.

11.5 Finding five: Existing responses are fragmented

The present environment contains several valid responses:

• manufacturers design security systems;
• regulators and standards bodies address vehicle cybersecurity;
• SERMI controls legitimate access to security-related repair information;
• police provide prevention advice and investigate offences;
• government targets electronic theft devices;
• insurers manage claims, pricing and fraud risk;
• aftermarket providers supply deterrents and recovery products;
• repairers and vehicle security operators perform technical work.

However, these responses do not create a single vehicle-level control record.

They do not consistently answer:

What is the known security-data status of this vehicle after this risk event?

That is the missing layer.

11.6 Finding six: VSD risk is strongest at lifecycle trigger points

The research identifies repeated lifecycle trigger points where VSD control may be appropriate:

• used vehicle purchase;
• one-key vehicle purchase;
• key loss;
• key theft;
• vehicle break-in;
• attempted theft;
• theft recovery;
• security-related repair;
• fleet handover;
• employee or contractor exit;
• rental or lease return after high-risk use;
• remarketing or resale;
• insurer request;
• owner concern or suspected compromise.

These triggers do not prove compromise. They identify where uncertainty becomes material enough to justify a control event.

The framework should therefore be risk-based, not universal.

11.7 Finding seven: A credible solution must be evidence-led and limited

A credible solution should not claim permanent protection.

It should produce a point-in-time control record.

The correct language is not:

“This vehicle cannot be stolen.”

The correct language is closer to:

That makes the model defensible.

It aligns VSD control with other risk-control environments, where audits, inspections and certificates evidence status at a defined point without guaranteeing future immunity.

11.8 Finding eight: VSD renewal and certification is a proportionate control response

A VSD renewal and certification model is proportionate because it addresses a specific gap.

It does not require the entire criminal-tool market to disappear. It does not require manufacturers to control every downstream event. It does not require police to certify technical repair status. It does not require insurers to determine VSD status through claims investigation alone. It does not require consumers to understand vehicle-security architecture.

Instead, it creates a repeatable control event.

That event can assess, renew, revoke, supersede, record or certify the relevant security-data state at a defined point in time.

This gives stakeholders something they currently lack: a common evidence language for vehicle-security-data control.

11.9 Final conclusion

Vehicle Security Data is a lifecycle risk.

It is created by the interaction between vehicle design, ownership transfer, key possession, repair access, digital credentials, criminal tools, organised theft, insurer evidence, fleet use and consumer uncertainty.

Because VSD can be copied or retained, it cannot be made permanently controllable by ownership alone. Because electronic and security-related tools exist in both legitimate and uncontrolled markets, it cannot be fully contained by manufacturers alone. Because criminal methods adapt, it cannot be fully contained by police alone. Because claims evidence often appears after loss, it cannot be fully contained by insurers alone. Because ordinary users cannot audit historic access, it cannot be fully contained by consumers alone.

The realistic objective is therefore not total prevention.

The realistic objective is defined control.

A better vehicle-security environment would allow exposed or suspected-exposed Vehicle Security Data to be assessed, renewed, revoked, recorded and certified at defined risk points, creating a transferable evidence record of security-data status at a point in time.

That is the research basis for a Vehicle Security Data Renewal and Certification Framework.

Appendix A

Source List

The following source list supports the research paper. Some entries are core evidence sources; others are supporting or contextual sources.

Appendix source-use hierarchy

Primary / core sources

• Home Office 2016 vehicle-security research.
• ONS vehicle-related theft data.
• Home Office electronic theft device policy.
• Police.uk guidance.
• RUSI organised vehicle theft research.
• SERMI UK / Europe.
• UK government vehicle cybersecurity principles.
• VCA / UN R155 / UN R156.
• ABI / FCA insurance evidence.

Secondary / supporting sources

• Thatcham material.
• Ireland PSA comparator.
• Essex Police / other police-force guidance.
• Insurer public guidance.

Contextual / illustrative sources

• RAC.
• Admiral.
• Autocar.
• Guardian.
• Police case studies.

The source hierarchy is designed to ensure that the research paper relies primarily on official, regulatory, industry-standard and independent research sources, while using journalism and consumer-facing guidance only for context or real-world illustration.

Publication notice

Publication notice