Security Center

Version: 1.0
Last modified: 27.07.2026

1. Purpose

RA Consulting (“RA”, “we”, “us”) attaches great importance to the security of its products, update mechanisms, and related services.

Despite careful design, implementation, testing, and maintenance, vulnerabilities may still be discovered. We welcome reports from security researchers, customers, users, partners, and other well-intentioned persons who identify potential security vulnerabilities affecting RA products or related RA-controlled services.

This policy explains how to report vulnerabilities, what is in scope, how RA handles and discloses reports, how security updates are communicated, and which research activities are not permitted. It supports coordinated vulnerability disclosure and RA vulnerability-handling obligations, including under Regulation (EU) 2024/2847, the Cyber Resilience Act, where applicable.

2. Scope of this policy

This policy applies to vulnerabilities affecting supported RA products and RA-controlled product-related services made available on the EU market or otherwise provided by RA.
Product security information, advisories, reporting instructions, support-period information, and update information are provided centrally through https://rac.de or another RA-controlled channel referenced from that website.

Products and assets in scope

The following are in scope:

1. RA standalone software products or mobile applications, including RA software used for OBD reading, vehicle diagnostics, diagnostic data processing, or related use cases;
2. Supporting software, including installers, packages, libraries, drivers, plugins an extensions produced by RA;
3. Licence, activation, registration, and entitlement mechanisms, where security relevant;
4. RA-managed remote data processing, cloud services, web services, or APIs, where they are required for or directly related to the operation of an RA product;
5. Third-party or open-source software components included in, distributed with, or required by an RA product, where the issue affects the product or its security.

Assets and activities out of scope

The following assets and activities are generally outside the scope and not accepted as direct testing targets. A report involving one of these assets or activities may still be accepted for triage where the reporter demonstrates a concrete, reproducible security impact on a supported RA product, RA-controlled service, RA customer data, or RA product supply chain.

Out of scope:

• unsupported or end-of-life RA product versions;
• third-party websites, services, repositories, stores, portals, or infrastructure not controlled by RA;
• customer systems, customer networks, customer databases, customer vehicles, vehicle ECUs, workshops, fleets, or test environments not owned or expressly authorised by the reporter;
• third-party OBD adapters, cables, diagnostic hardware, operating systems, vehicle systems, or drivers.

3. Definition of a vulnerability

For the purpose of this policy, a security vulnerability is a weakness, flaw, design or implementation issue, configuration issue, missing security control, insecure dependency, or similar issue in an RA product or RA-controlled related service that could compromise confidentiality, integrity, availability, authenticity, safety, or security of the product, of RA product or RA-controlled service.

Examples include, but are not limited to:

• remote code execution;
• local privilege escalation caused by RA software;
• authentication or authorisation bypass;
• arbitrary file read, write, overwrite, or deletion;
• insecure handling of data;
• unauthorised access to customer, licence, diagnostic, account, or product data;
• cryptographic vulnerabilities with practical impact;
• insecure storage of secrets, credentials, tokens, private keys, or sensitive diagnostic data;
• command injection, SQL injection, XML external entity injection, server-side request forgery, deserialisation issues, or memory corruption;
• exploitable vulnerabilities in third-party or open-source components included in an RA product;
• vulnerabilities in RA product download, update, licence, activation, or security-advisory mechanisms;
• actively exploitable backdoors or malicious functionality.

Low-impact findings normally out of scope

Findings are normally out of scope where they do not demonstrate practical security impact, including missing best-practice headers or cookie flags, version disclosure, descriptive errors, clickjacking, low-impact CSRF, content spoofing, weak CAPTCHA, username enumeration, rate-limiting issues, self-XSS, scanner-only reports, unsupported product or platform issues, non-sensitive information disclosure, outdated-component reports without evidence of RA product impact, and UI, UX, translation, spelling, or CSV-injection issues without demonstrated impact.

Source-code disclosure remains in scope where it involves leaked secrets, keys, credentials, unreleased code, build-system access, or exploitable source disclosure. TLS, DNS, email-security, and corporate web-configuration findings are generally out of scope unless they affect product security, downloads, updates, reporting, authentication, customer data, trusted RA security communications, or the RA product supply chain.

4. Rules of engagement

Security research must be performed in a safe, lawful, non-destructive, and privacy-preserving manner.

You may:

• test RA standalone software and supporting services in an environment that you own or are authorised to use;
• submit non-destructive proof-of-concept information;
• report vulnerabilities affecting RA products, update mechanisms, product components, or RA-controlled product-related services;
• report anonymously, provided the report is detailed enough for RA to assess the issue.

You must not:

• break applicable laws or regulations;
• access, copy, modify, delete, encrypt, exfiltrate, or disclose data, accounts, licences, tokens, systems, vehicles, customer environments, or information without authorisation;
• perform denial-of-service, resource-exhaustion, stress, load, or destructive testing against RA systems or services;
• disrupt product downloads, update services, licence services, support services, security reporting channels, or customer operations;
• introduce malware, ransomware, backdoors, persistence mechanisms, or destructive payloads;
• use phishing, spam, social engineering, credential stuffing, password spraying, brute force, or MFA fatigue techniques;
• perform physical attacks or attacks against RA premises, employees, customers, or suppliers;
• use RA products to send commands, diagnostic requests, or payloads to vehicles or ECUs in a way that may affect vehicle safety, road safety, emissions compliance, warranty, or availability;
• publicly disclose vulnerability details before RA has had a reasonable opportunity to validate, remediate or mitigate, and coordinate disclosure.

If you accidentally access personal data, customer data, confidential information, secrets, credentials, private keys, or other sensitive data, stop testing immediately, avoid further access or sharing, notify RA promptly, and securely delete the data as soon as it is no longer required for reporting.

5. How to report a vulnerability

Please report vulnerabilities in German or English.

Primary contact: psirt@rac.de
Backup contact: csirt@rac.de
Reporting form: https://www.rac.de/company/legal/security-contact/?lang=en

Please use the primary contact where possible. Use the backup contact if the primary contact is unavailable or if you have not received an acknowledgement within the timeframe stated below. Sensitive reports may be encrypted using RA’s OpenPGP key.

Do not send active malware, destructive payloads, stolen data, personal data, or confidential third-party data unless strictly necessary. Contact RA first to agree a safe transfer method.

6. Information to include in a report

A useful vulnerability report should include as much of the following information as possible:

• a short summary of the vulnerability;
• affected RA product name and affected product version;
• operating system, architecture, and relevant environment details;
• whether the issue affects standalone use, update, activation, licensing, log handling, diagnostic communication, or another product function;
• whether the issue affects a third-party or open-source component, including component name, version, CVE identifier, advisory link, and evidence that the component is included in or reachable through an RA product;
• step-by-step reproduction instructions;
• proof of concept, screenshots, logs, crash dumps, or screen recordings, where safe and appropriate;
• expected and actual behaviour;
• potential impact, including what data, system access, product function, user, customer, or update mechanism may be affected;
• whether the vulnerability is known to be actively exploited;
• possible mitigations, workarounds, or fixes, if known;
• your preferred contact details, unless you report anonymously.

Please redact secrets, personal data, and other sensitive information unless they are strictly necessary to understand the vulnerability.

7. RA vulnerability handling process

RA will handle vulnerability reports through a coordinated vulnerability handling process.

Receipt and acknowledgement

RA aims to acknowledge receipt within 5 business days. If you have not received an acknowledgement within 10 business days, you may use the backup contact. Acknowledgement confirms receipt only and does not confirm the vulnerability.

Tracking and triage

Upon receipt, RA will review the report and may assign an internal tracking number. RA will assess the vulnerability’s scope, reproducibility, security impact, affected versions, evidence of active exploitation, affected users or data, and any supply-chain impact.
Where required, RA will coordinate with relevant third parties, including suppliers, open-source projects, customers, partners, CSIRTs, ENISA, or other competent authorities.
RA may ask for additional information if needed.

Severity and prioritisation

RA prioritises confirmed vulnerabilities based on severity, exploitability, support status, remote or local access conditions, authentication and user-interaction requirements, affected users, systems, data, available mitigations, safety or customer impact, and evidence of active exploitation. RA may use CVSS where appropriate and may adjust severity for product-specific context.

Remediation and mitigation

RA will remediate or mitigate confirmed vulnerabilities without undue delay, taking into account their severity, product risk, other relevant criteria, and available technical options.

Outcomes may include a security update, configuration change, workaround, third-party or open-source coordination, or no fix where the report is not a vulnerability, is out of scope, affects only unsupported versions, or has no practical security impact.
RA may ask the reporter to verify a proposed fix.

Communication with the reporter

RA aims to keep the reporter informed of relevant milestones. The timing and detail of updates may depend on the issue’s severity, complexity, or other relevant circumstances.

If you comply with this policy and act lawfully, responsibly, and without harm, RA does not intend to initiate legal action for good-faith security research related to the reported vulnerability. This does not apply to unlawful, harmful, extortionate, coercive, destructive, fraudulent, privacy-invasive, criminal, intelligence-related, or policy-inconsistent activity.

Security updates and mitigations

During the defined support period for an RA product, RA will handle product vulnerabilities and provide security updates, mitigations, or other corrective measures where appropriate.

Updates may be distributed through RA’s official website, product update mechanisms, or other RA-controlled channels. Users are responsible for applying available updates and mitigations within a reasonable time and in accordance with RA’s instructions.

8. Support periods

RA handles vulnerabilities for each product during its defined support period. The applicable support period, including the support end date where required, is provided through RA-controlled channels such as user instructions, customer contracts, or official communications.

RA may review reports for unsupported or end-of-life products where active exploitation, significant user risk, or supported-product impact exists, but does not guarantee security updates unless required by law or contract. RA may recommend upgrading to a supported version.

9. Regulatory reporting and public vulnerability disclosure

RA supports coordinated vulnerability disclosure. We will assess each report to determine the required remediation, user communication, public disclosure, and any legal or regulatory reporting obligations, including under the Cyber Resilience Act where applicable.

RA may share necessary information where needed to validate the issue, coordinate a fix, protect users, involve affected third parties, or comply with legal or authority reporting obligations. We will protect the reporter’s identity and personal data where possible, but may disclose such information with the reporter’s consent, where necessary for coordinated handling, or where required by law or competent authorities.

Reporters should not publicly disclose vulnerability details until RA has had a reasonable opportunity to validate the issue, provide a fix or mitigation where appropriate, and allow users reasonable time to apply it. For fixed or mitigated vulnerabilities in supported products, RA will publish appropriate advisory information unless disclosure would create a security risk or is legally restricted. RA may delay, limit, or coordinate advisory content where necessary to protect users, avoid exposing unfixed issues, comply with law, or coordinate with affected third parties.

10. Privacy and confidentiality

RA treats vulnerability reports confidentially and processes personal data only for vulnerability handling, investigation, remediation, disclosure coordination, legal compliance, and communication with the reporter. Reporters should minimise personal and confidential data. RA may share report information only where necessary for validation, remediation, coordination, disclosure, or legal obligations. RA will not identify the reporter in a security advisory unless agreed or legally required.

11. Rewards, bug bounty, and compensation

RA does not operate a public bug bounty programme and does not guarantee monetary compensation. Any reward, gift, acknowledgement, or public credit is provided solely at RA’s discretion. RA may decline recognition for out-of-scope, already known, low-detail, scanner-only, prohibited, or policy-inconsistent reports.

12. Legal terms

This policy does not permit activity that violates applicable laws or regulations and does not replace product terms, licence terms, customer agreements, confidentiality obligations, export-control rules, data-protection obligations, vehicle-safety obligations, or mandatory legal requirements. RA may update this policy from time to time. The latest version is published on RA’s official website.