Modern diagnostics: connecting a scan tool no longer guarantees full access

A connection is not full access

A scan tool connected to a vehicle’s diagnostic port may communicate with one or more systems and still lack authorization to perform every available operation. Separate four levels: connection to the car, communication with a particular control unit, availability of the required function and permission to use it. These are different outcomes. Saying only that «the machine was plugged in» does not establish which level was reached.

This distinction matters in a workshop and when assessing a used car. A limited scan can be useful and reveal information, but it cannot be presented as a complete inspection if that inspection depended on systems or functions that were inaccessible. Nor does an absence of fault codes in the systems that were checked prove that no issue exists elsewhere, or that an intermittent fault did not simply fail to occur during the test. The scope needs to be clear before anyone interprets the result.

Define the question before connecting the tool

Before a diagnostic session, agree on the decision the test is meant to inform. Reading codes, viewing data, running a guided test, performing an adaptation and verifying a repair are not equivalent tasks. Describe the symptom and ask what operation is proposed, which systems need to be queried and what result would confirm or rule out each hypothesis. This prevents a vague request for a «complete diagnosis» when nobody has agreed what that means for this vehicle and situation.

Hypothetical example: if a warning light appears intermittently, reading stored codes may be a useful first step, but it may not reproduce the event or identify its cause. Depending on the case, a technician may need to record the circumstances, inspect connections or compare signals. If a necessary check requires a function the tool does not cover, that should be listed as outstanding. It should not be treated as completed merely because another part of the session worked.

What SDA offers—and what it does not establish

Bosch describes Secure Diagnostic Access (SDA) as a way to access protected vehicle electronics from participating manufacturers through ESI[tronic]. User identification uses SingleKey ID, and some operations require additional steps. Bosch also says availability depends on country, licenses and coverage. SDA’s existence therefore does not establish that any Bosch tool, workshop or user can access every function on every car.

For a customer, the practical question is not just whether the workshop owns a tool of a particular brand. Ask whether the tool, software version, license and authorized access cover the specific make, model, year and function required. The answer can depend on the vehicle configuration and requested operation. If access is unavailable, ask the workshop to document the limitation and explain its proposed alternative diagnostic route. Do not confuse an access restriction with a negative technical finding.

Check coverage and authorization separately

Coverage asks whether the tool offers the function for that particular variant; authorization asks whether the person doing the work can use it through the required procedure. They are not interchangeable. Before approving a diagnostic estimate, confirm both for the specific operation and clarify whether it involves reading, an active test, coding or another function. A platform’s commercial name or the presence of a connector is no substitute for that confirmation.

If coverage or authorization is missing, the next step depends on the goal. The workshop may suggest an alternative test, arrange appropriate access or refer the operation to another capable provider. Ask which option is being considered and what part of the diagnosis will remain unresolved. Do not share credentials or agree to bypass a security measure: secure access is intended to support work through authorized procedures. Bosch describes SDA and general availability conditions, but that does not confirm access for a particular workshop.

Turn a fault code into a testable hypothesis

A fault code is a clue to interpret alongside the symptom, operating conditions and other tests; on its own, it does not prove that the part named on screen has failed. Ask what observation triggered the code, whether it is active or stored, and what check would distinguish the possible causes. The explanation should show the reasoning rather than leap directly from text on a screen to replacing a part.

Hypothetical example: a code related to an implausible signal might prompt checks of the sensor, its connection and the conditions under which the reading occurred. Which tests are appropriate depends on the vehicle and available information; this example does not prescribe a universal repair. If a test could not be run because access, coverage or authorization was missing, that absence neither confirms nor rules out the hypothesis. A sound conclusion may be provisional and identify the evidence still needed to proceed.

What a useful report should contain

Ask for a record identifying the vehicle, date, reported symptom and relevant conditions when the checks were performed. It should state which systems were queried, which functions were attempted, what results were obtained and what could not be checked, including the reason where known. A list of codes without context is less useful than an explanation linking each finding to the test that supports it and to the recommended decision.

An estimate and a report serve different purposes: the estimate proposes work and cost; the report should make the available evidence and its limits understandable. Ask how the outcome will be verified after a proposed repair and what finding would change the recommendation. If the session was partial, ask that it be identified as such instead of accepting the label «complete inspection». This makes it easier to compare opinions and prevents an initial hypothesis from being treated as a confirmed cause.

Decide what to do when inspecting a car before purchase

For a pre-purchase inspection, agree on the scope before paying or making a decision. Find out whether the systems relevant to the reported symptom will be checked, what access limitations might arise and whether the inspection includes physical checks as well as an electronic scan. A clean reading from accessible systems does not guarantee the whole vehicle is in good condition; conversely, limited access does not prove a defect exists. Both points should be stated without overstating what they mean.

Use the report to choose a next step, not as a guarantee. If an important function remains unchecked, you can request a further assessment, ask the seller to authorize an appropriate check or reconsider the purchase if you are unwilling to accept the uncertainty. Confirm who will do the work, what will be delivered and any cost or condition before commissioning it. The practical sequence is simple: define the question, confirm access, keep the report and decide based on what is demonstrated and what remains open.

Questions answered

Keep reading

• ADAS Calibration: What Should Be Clear After a Repair
• Used EV battery health reports: how to interpret the results
• How to Arrange a Car Inspection in Germany: A Buyer’s Checklist