Car Dealership Software Security: Lessons From the DMS Outage

A dealership cannot secure its DMS vendor, but it can control five things: an offline fallback runbook, least-privilege and expiring API tokens for every connected tool, audit logs, tested restores, and MFA everywhere. The lesson comes from June 2024, when a cyber incident at CDK Global, which serves about 15,000 North American dealers (CBS News), pushed US and Canadian dealerships onto manual processes.

This guide is for dealer principals, dealer group IT and operations leads, and the developers who build the tools that sit beside a DMS. A plain statement first: RAITHub has not shipped an automotive product or a DMS integration. What follows is engineering guidance, drawn from access control, audit and payment work RAITHub has shipped on other platforms, and from what the affected dealer groups and CDK said in public at the time.

What actually happened in the CDK Global outage?

Only what the sources confirm. On 19 June 2024, CDK Global notified its dealer customers of a cyber incident and suspended systems. Two large listed dealer groups described what that meant for them in SEC filings made on 24 June 2024:

• Lithia Motors said it "received notice from CDK Global ... that CDK had suspended systems used by the Company in response to a cybersecurity incident impacting CDK". It said it "activated its cyber incident response procedures", including "severing business service connections between the Company's systems and CDK's", and that it had "not identified any compromise or unauthorized access of its systems or networks" (Lithia Motors Form 8-K).
• AutoNation said the incident affected "the systems necessary to support our dealer management system", disrupting sales, service, inventory and accounting, while "all of our locations remain open, and we are continuing to sell, service, and buy vehicles" using alternative, manual processes at reduced productivity (AutoNation Form 8-K).

During restoration CDK said a "small initial test group" of dealers had been brought back and that it was "actively working to bring live additional applications—including our Customer Relationship Management (CRM) and Service solutions"; news reports described dealers writing repair orders by hand and moving to paper (Yahoo News, reporting CDK's update). Dealer filings track the restoration: on 5 July 2024 Sonic Automotive said basic DMS functionality was back while its CRM and some DMS functions were still offline (Sonic Automotive Form 8-K), and on 15 July AutoNation said its DMS and core functions were restored, with some ancillary integrations expected back before the end of July (AutoNation Form 8-K).

This post goes no further on cause or attribution than that. Those questions belong to CDK, investigators and the courts. The useful question for everyone else is narrower: when a system you depend on goes dark for two weeks, what did you prepare, and what did you connect to it?

Could my dealership keep selling cars if the DMS went down tomorrow?

Only if the fallback is written down, printed, and rehearsed before the day. AutoNation's filing is the useful model: locations stayed open and kept selling, servicing and buying on manual processes. That is not luck; it is a runbook. The US Cybersecurity and Infrastructure Security Agency's ransomware guide says to "create, maintain, and regularly exercise" an incident response plan and to "ensure a hard copy of the plan and an offline version is available" (CISA #StopRansomware Guide).

A dealership fallback runbook covers, per department:

• Sales: paper deal jackets, a printed rate and fee sheet, who can approve a deal without the desking tool, and how deals are keyed back in later.
• F&I: which lender portals can be reached directly, outside the DMS, and who holds those logins (with MFA on a device that does not depend on the DMS).
• Service: blank repair-order forms, a printed labour-rate card, and a daily export of the next week's appointments held outside the DMS so customers are not turned away blind.
• Parts: a recent stock snapshot, and the rule for counter sales without live stock.
• Accounting: how cash, cards and cheques are logged, and the order in which transactions are re-entered when systems return.
• Communications: an out-of-band contact list for staff, the vendor and lenders, and a pre-agreed script for customers.

The runbook is only real once a rooftop has run a two-hour drill on it. The first drill always finds a missing form or a login that only exists in a browser that no longer works.

What does vendor concentration mean for a dealer group?

Vendor concentration is how much of the business stops when one supplier stops. For many dealers the DMS vendor also supplies the CRM, the service scheduler and the digital retail tools, so one incident touches every department at once. AutoNation's and Lithia's filings both list sales, inventory and accounting in the blast radius, and Lithia names its CRM too.

You cannot remove the concentration; a franchised dealer runs one DMS. You can reduce what stops with it. Keep a copy of the data you need to trade (appointments, open deals, stock, customer contacts) somewhere the vendor does not host, refreshed daily, access-controlled and encrypted. Keep lender and manufacturer portal access independent of the DMS. And make disconnection a switch rather than a scramble: Lithia's first steps included severing connections between its systems and CDK's. Every tool you connect should be easy to cut off and easy to reconnect.

How should third-party tools connect to a DMS?

Each tool gets its own credential, with only the permissions it needs, for a limited time, and every use is logged. The lead router needs to write leads, not read finance applications. The website needs to read inventory, not change prices. One shared admin login for "the integrations" means one leaked password exposes everything, and nobody can tell which tool did what.

What access your DMS vendor offers, and on what terms, is set by the vendor and your contract. What you control is the credentials you issue inside your own tools and data layer: the inventory mirror, the lead router, the reporting warehouse. The schema below is a minimal version of that.

What does a scoped, expiring API token and an audit log look like in SQL?

Two PostgreSQL tables: tokens that are hashed, scoped, limited to rooftops and forced to expire within 90 days, and an append-only audit log. This sample was written for this post as a minimal illustration, not taken from any client codebase.

-- One row per integration credential. The raw secret is shown once at
-- creation; only its SHA-256 hash is stored.
CREATE TABLE api_token (
  id           uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  name         text NOT NULL,          -- e.g. 'website-inventory-read'
  owner_email  text NOT NULL,          -- a person accountable for it
  token_hash   bytea NOT NULL UNIQUE,
  scopes       text[] NOT NULL,
  rooftop_ids  uuid[] NOT NULL,
  created_at   timestamptz NOT NULL DEFAULT now(),
  expires_at   timestamptz NOT NULL,
  last_used_at timestamptz,
  revoked_at   timestamptz,
  CHECK (cardinality(scopes) > 0 AND cardinality(rooftop_ids) > 0),
  CHECK (scopes <@ ARRAY['inventory:read', 'leads:write',
                          'appointments:write', 'deals:read']::text[]),
  CHECK (expires_at <= created_at + interval '90 days')
);

-- Append-only: the application role may insert and read, never change.
CREATE TABLE audit_event (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  occurred_at timestamptz NOT NULL DEFAULT now(),
  actor_type  text NOT NULL CHECK (actor_type IN ('user', 'api_token', 'system')),
  actor_id    uuid NOT NULL,
  rooftop_id  uuid,
  action      text NOT NULL,           -- 'deal.view', 'token.create', 'export.run'
  target_type text NOT NULL,
  target_id   text NOT NULL,
  ip          inet,
  detail      jsonb NOT NULL DEFAULT '{}'
);
GRANT SELECT, INSERT ON audit_event TO app_rw;
REVOKE UPDATE, DELETE, TRUNCATE ON audit_event FROM app_rw;

-- Authenticate a request: $1 is the presented secret as text.
SELECT id, scopes, rooftop_ids
FROM api_token
WHERE token_hash = sha256(convert_to($1, 'UTF8'))
  AND revoked_at IS NULL
  AND expires_at > now();

How it is used: the application checks that the requested action's scope is in scopes and the rooftop is in rooftop_ids, updates last_used_at, and writes an audit_event row for every sensitive read or write. Revoking a token is one update, and a token that nobody renews simply stops working, which is what you want from a credential issued to a vendor that has since been replaced.

Honest limits. A SHA-256 hash is appropriate for long random tokens, not for passwords, which need a slow hash. The scope list in the check constraint is a starting point; add scopes deliberately rather than widening an existing one. And an append-only table still needs a copy outside the database, because an attacker with owner rights can drop it. The fuller design, including retention and export, is in how to design a SaaS audit log, and role and permission design is in SaaS authorisation and RBAC design.

Dealership software security checklist

Control	What good looks like at a dealership	Rough effort
Offline fallback runbook	Printed per department, with forms, contacts and a re-entry order; drilled once or twice a year	Days, not weeks
Independent copy of trading data	Daily encrypted export of appointments, open deals, stock and contacts, held outside the DMS vendor	A small build or a vendor feature
Least-privilege API tokens	One credential per tool, scoped by action and rooftop, expiring within 90 days, with a named owner	A small build per integration
Kill switch per integration	Any connection can be cut in minutes and restored cleanly	Design time; cheap if planned
Audit logs	Append-only record of who viewed or changed deals, customer records and tokens, copied off the database	A small build
Backups and restore drills	Offline, encrypted backups of anything you host; a timed restore test on a schedule	Hours per drill
MFA	On email, lender portals, remote access, admin panels and every tool that touches customer data	Hours to days
Rate limiting and alerting	Limits on login and public endpoints; alerts on unusual export volume	A small build
Vendor oversight	A written list of every provider with access to customer data, what they hold and how to reach them in an incident	A spreadsheet and a review
Phishing-aware procedures	During any outage, staff verify "vendor support" calls and emails through a known number before acting	A briefing and a script

Effort figures are rough engineering judgement for a small dealer group, not a quote. The lowest-cost items on the list, the runbook, the provider list and the call-back rule, are also the ones most often missing.

How often should a dealership test its backups?

Often enough that a restore is a routine, timed task rather than a first attempt during an incident. CISA advises keeping "offline, encrypted backups of critical data" and to "regularly test the availability and integrity of backups in a disaster recovery scenario" (CISA #StopRansomware Guide). For the systems a dealer hosts itself, such as a website, a lead router or a reporting database, a quarterly restore into a clean environment is a reasonable starting point. Record how long it took and what broke. The DMS data itself is the vendor's backup to run; ask in writing what their recovery objectives are and what export you can take.

Does the FTC Safeguards Rule apply to car dealerships?

For many US dealers, it may. The rule applies to "financial institutions" as defined in the regulation, and its own examples include "an automobile dealership that, as a usual part of its business, leases automobiles on a nonoperating basis for longer than 90 days", which "is a financial institution with respect to its leasing business" (16 CFR 314.2). Whether arranging or extending financing brings your dealership in scope is a question for your adviser.

Where it does apply, the FTC's guidance lists elements such as designating a Qualified Individual, a written risk assessment, access controls, encrypting customer information at rest and in transit, "multi-factor authentication for anyone accessing customer information on your system", overseeing service providers, a written incident response plan, and notifying the FTC within 30 days of discovering certain events involving 500 or more consumers. Some provisions do not apply to entities holding information on fewer than 5,000 consumers (FTC Safeguards Rule guidance). Canadian dealers have their own privacy law obligations.

This is general information, not legal advice; confirm with your adviser.

What should a developer building DMS-adjacent tools get right?

• Fail closed and degrade gracefully. If the DMS feed stops, the website shows the last known stock with a banner, rather than emptying or showing stale prices as current.
• Idempotent sync. When a vendor reconnects after days offline, jobs replay. Every write should be safe to run twice.
• No customer data you do not need. A lead router needs contact details and a vehicle, not a credit application.
• Secrets out of code. Tokens live in a secret store, rotate on a schedule, and never appear in logs.
• Tests on the permission rules. Every scope and rooftop boundary gets an automated test that proves the wrong caller is refused.

Why RAITHub for this

• Access control is shipped work. Sundor Skin, the B2B wholesale platform RAITHub built, runs 88 permission codes across 12 staff roles on PostgreSQL row-level security (Sundor Skin case study). Per-rooftop, per-role access at a dealer group is the same shape of problem.
• Money paths tested properly. PropDesk, the property management platform RAITHub built, collects rent through Stripe and carries 1,024 automated tests (PropDesk case study).
• Routing and abuse controls. Lead routing sits at the core of BlockEstate, and this site runs rate limiting on its public endpoints without a Redis dependency (rate limiting without Redis).
• Honest about the boundary. RAITHub has not shipped an automotive product or a DMS integration, and is not SOC 2 or ISO 27001 certified. It signs DPAs, follows your controls and your DMS vendor's integration terms, and can answer a vendor questionnaire plainly (answering a security questionnaire without SOC 2).
• Hours that reach you. RAITHub works from Dhaka (UTC+6). US and Canadian clients get a daily 2-hour evening overlap, Dhaka 19:00 to 21:00, which is 08:00 to 10:00 in New York and Toronto in winter and 09:00 to 11:00 in summer. The working week is agreed per client, and the rest runs on written daily handoffs.
• Fixed scope. A free 15-minute technical audit, then a written fixed quote. You own the code, and an NDA is standard.

When you don't need us

• You need an incident responder today. If you are in an active incident, call your insurer's breach line, your DMS vendor and a specialist incident response firm first.
• You need a penetration test or a certification. Hire an accredited testing firm; RAITHub fixes what they find.
• You need legal advice on the Safeguards Rule. That is your adviser's job, not a developer's.
• Your only gap is the runbook. Writing and drilling it is an operations task. You do not need developers for it.
• You want developers placed in your team by the hour. RAITHub offers fixed-scope builds and dedicated teams, not staff augmentation.

If the tools around your DMS share one login, keep no logs or have never been restored from backup, the API and backend development service covers scoped credentials, audit trails and resilient sync, and /fix handles a single broken integration. More on how RAITHub handles client code and data is on the security page. Book the free 15-minute technical audit with a list of every tool connected to your DMS and how each one logs in.

Last reviewed: 1 October 2026. SEC filings, FTC guidance and CISA guidance checked on 1 October 2026.

Frequently asked questions

What happened to CDK Global in June 2024?

CDK Global, a dealer management system vendor serving about 15,000 North American dealers, had a cyber incident on 19 June 2024 and suspended systems. Dealer groups including AutoNation and Lithia Motors disclosed the disruption in SEC filings and kept trading on manual processes while CDK restored service over the following weeks.

Was dealership customer data exposed in the CDK outage?

The dealer filings cited here do not settle it for every dealer. Lithia Motors said it had not identified compromise or unauthorised access to its own systems. For your dealership, rely on CDK's own notices to you, regulator filings and your adviser, not on secondary reports.

What is the first security step a dealership should take?

Write and print a fallback runbook for each department, then drill it. It costs days, not money, and it decides whether you can keep selling and servicing cars when a critical system is offline.

Do car dealers have to follow the FTC Safeguards Rule?

Many may. The regulation's own examples name a dealership that leases vehicles for more than 90 days as a financial institution for its leasing business. Whether your dealership is covered depends on what it does, so confirm with your adviser.

How should third-party tools authenticate to dealership systems?

With one credential per tool, scoped to the actions and rooftops it needs, expiring within a set period such as 90 days, stored hashed, owned by a named person, and logged on every use. Access to the DMS itself follows your vendor's programme and contract.

Has RAITHub built security for a dealership before?

No. RAITHub has not shipped an automotive product or a DMS integration. It has shipped the underlying patterns: 88 permission codes and 12 roles on Sundor Skin, Stripe payments with 1,024 tests on PropDesk, lead routing on BlockEstate and rate limiting on this site.