Fast triage: what is actually failing?
Most transport cyber incidents present first as an operational problem, not a technical one. Dispatch cannot see jobs. Drivers have no routes. Customers are calling about loads that should have moved. The question is not immediately “were we hacked?”. The question is “what is failing and does this look deliberate?” Five diagnostic questions narrow this down within ten minutes.
Five questions to ask first
- Is it identity or email? Logins failing, MFA prompts appearing unexpectedly, unusual inbox rules, sent items nobody sent.
- Is it the planning stack? TMS or ERP unavailable, jobs not flowing, integrations timing out.
- Is it endpoints? Multiple PCs running slow, encrypted files, AV alerts firing across the depot.
- Is it connectivity? Distinguish between DNS, ISP, or VPN outage and an active network attack. Call your IT provider before assuming either.
- Is money involved? Bank detail changes received or sent, invoices rerouted, supplier payment instructions altered.
Do not do these under pressure
- Do not mass-reboot “to fix it”. You destroy evidence that determines your insurer and ICO position.
- Do not delete emails or logs to “clean up”. Preserve everything. Document before acting.
- Do not reset all accounts simultaneously. Start with admin and finance accounts.
- Do not communicate through the potentially compromised mailbox. Switch to phone or a secondary channel.
- Do not assume it is an IT problem. If dispatch is down and drivers are stranded, this is an operations continuity incident.
Unlike an office environment, transport incidents have an immediate physical consequence. A planning system that goes dark at 06:00 means drivers sitting at depot waiting for jobs that are not coming, loads missing collection windows, and customers calling by 08:00. The five failure modes below all produce this cascade. The difference is where they start and what you do first to stop them spreading.
The five failure modes.
Different fleets, different systems, consistent patterns. The specific TMS or telematics platform changes. The underlying exposures do not. Each failure mode is mapped across three dimensions: the early warning signs that appear before the full impact, the first actions that contain it calmly, and the controls that reduce its likelihood.
An attacker takes over a mailbox, typically a manager, finance lead, or operations user, and uses it to reroute payments, change supplier bank details, send fraudulent instructions to customers or subcontractors, or intercept ongoing negotiations about loads and contracts. The compromised account looks completely legitimate because it is: it is the real account, sending from the real address, often with a full email history behind it. By the time the fraud is discovered, the transfer has been processed and recall is unlikely.
MFA prompts appearing at unexpected times, especially on mobile during working hours when the user is not logging in.
New inbox rules appearing that forward, delete, or move messages to folders the user did not create.
Clients or suppliers saying your emails “look different” or that they received requests they were not expecting from your address.
Missing sent items, or sent items the account holder did not send.
Freeze any payments or bank detail changes that arrived via email in the affected period. Do not process until verified by voice call to a number you hold independently.
Revoke sessions and reset the compromised account. Revoke refresh tokens before resetting the password. Check for attacker-added MFA methods and remove them.
Audit inbox rules, forwarding settings, and delegates on the affected account and adjacent accounts (same team, finance, directors).
Contact affected suppliers and customers factually: confirm what communications to treat as suspect and how to verify legitimate instructions.
MFA enforced on all email accounts, including depot and operations staff, not just directors. Phishing-resistant methods (FIDO2) where available; push-based MFA is better than nothing but is vulnerable to fatigue attacks.
DMARC at enforcement (p=quarantine or p=reject), DKIM, and SPF. These prevent your domain being spoofed from outside, which is a separate attack vector.
Payment verification policy: no bank detail change processed based on email instruction alone. Voice callback to a number on file, not the number in the email.
Mailbox auditing enabled so sign-in anomalies and rule changes are visible when needed.
This is the scenario most transport operators think of first. Ransomware hits the systems dispatchers live in: no loads visible, no driver assignments, no route information, no proof of delivery history. Operations revert to phone calls and wherever data was last exported. Without a tested recovery procedure and a manual-mode fallback, the average transport firm takes three weeks to restore full function. Every day of that three weeks has a direct and measurable cost in missed collections, penalty clauses, and customer relationship damage that does not fully recover.
AV or EDR alerts firing across multiple machines simultaneously, rather than isolated events.
Abnormal CPU or disk activity, especially on servers or NAS storage devices overnight or at weekends when they are not heavily used.
File extensions changed on shared drives, or users reporting they cannot open files that were accessible yesterday.
RDP or VPN logins from unfamiliar IP addresses or geographies, particularly outside normal working hours.
Isolate affected endpoints from the network using EDR isolation or physical disconnection. Do not power everything off: logs on running systems are preserved in memory.
Protect backups immediately: lock backup admin credentials, verify they are separate from domain credentials, and pause replication if contamination is suspected.
Identify the scope: which systems are affected and which are confirmed clean. Activate your manual-mode dispatch procedure for the clean systems and any remaining capacity.
Call your IR contact. Identify patient zero and the likely access vector before remediation decisions are made.
Tested backups with isolation. Not “we have backups”: evidence of a successful restore from backup for your TMS and critical dispatch systems within the last six months, with a documented recovery time.
Remove exposed RDP from the internet. MFA on all remote access (VPN, remote desktop where it cannot be removed entirely).
Patch discipline: the most common ransomware entry points in transport are unpatched VPN appliances and exposed remote desktop. These are not sophisticated attacks.
EDR on depot and office endpoints. Network segmentation where feasible, at minimum separating operational systems from general internet access.
Documented manual-mode procedure so dispatch can continue at reduced capacity while recovery progresses.
Whether it is a SaaS vendor outage, credential theft targeting the planning system, a misconfiguration following an update, or a vendor-side compromise that cascades to your environment: if the TMS or ERP stops accepting or distributing jobs, dispatch is immediately forced into manual mode. The difference between this failure mode and ransomware is that the rest of your systems may be working fine. The chokepoint is the planning layer specifically. This includes the EDI integrations that receive load instructions from major customers: if the EDI feed breaks, the jobs simply stop arriving.
Users locked out of the TMS or ERP, or seeing permission errors on functions that worked yesterday.
API or EDI integration failures: customer portals reporting errors, automated job imports stopping without explanation.
Unexpected admin events: new users created, permission changes, unusual data exports, or configuration changes not initiated by your team.
Vendor status page showing nothing, while your instance is experiencing problems: this can indicate a targeted issue rather than a platform-wide outage.
Distinguish vendor outage from compromise before acting. Call your vendor on a number you hold independently, not via the support link in the application. If they confirm no outage, treat it as a potential compromise.
Freeze admin changes in the platform and rotate admin credentials if compromise is suspected. Do not wait for confirmation: rotating credentials is reversible, failing to rotate is not.
Review audit logs inside the platform for the last 48 hours: user creation, permission changes, data exports, and API access events.
Activate your manual dispatch fallback: printed or offline load lists, direct customer calls for critical deliveries, driver check-in by phone.
Separate admin accounts for the TMS and ERP: the account used for day-to-day dispatch is not the same account that can make admin-level changes. Admin accounts have MFA and are used only when needed.
Least privilege: dispatch users cannot export bulk data or modify integrations. Finance users cannot modify load planning. Separate roles for separate functions.
Vendor risk check: does your TMS vendor have an incident notification obligation in their terms? Do you have a named technical contact at the vendor, not just a support ticket queue?
Documented manual mode: what does dispatch do when the TMS is unavailable for four hours? For eight hours? For a full day? The answer needs to exist before the question is real.
Telematics compromise or failure removes fleet visibility: operations cannot see where vehicles are, drivers cannot receive route updates or proof-of-delivery instructions, and customers expecting tracking updates start calling. This can stem from a vendor-side compromise, credential theft targeting the telematics admin portal, SIM-based abuse on data-connected units, or a combination of poor device management and a targeted attack. It is less likely to halt operations completely than a TMS failure, but the downstream customer impact and the loss of evidence that telematics data provides post-incident makes it more consequential than it initially appears.
Devices dropping off the telematics map, or appearing in locations inconsistent with their actual position.
Driver app login failures across multiple vehicles simultaneously, rather than isolated device issues.
Push notification failures to the driver app for job updates or route changes.
Unexpected firmware updates or configuration changes on in-cab units not initiated by your fleet team.
SIM data spend anomalies on vehicle SIMs without a corresponding operational explanation.
Check vendor status first. Most telematics outages are vendor-side and affect multiple customers. If the vendor confirms no issue, treat it as a potential compromise of your tenant.
Lock down the telematics admin portal: rotate credentials and verify MFA is enforced for all admin accounts, not just the primary account.
Check device enrolment lists for devices that should not be present, and check admin-level changes made in the last 48 hours.
Switch critical loads to manual driver check-in cadence by phone: departure, on-site, and delivery confirmation calls until visibility is restored.
MFA on all telematics portal logins, including read-only accounts. Telematics portals with unprotected credentials are a straightforward target for credential stuffing.
Device management for company mobiles used with driver apps: the ability to remotely wipe or lock a compromised device without affecting the rest of the fleet.
Tight admin rights: the person who views tracking data is not the same account that can change device configuration or add new units.
Documented comms plan for tracking outages: what do you tell customers when tracking is unavailable, and who makes those calls? Writing this during an outage is too late.
Attackers do not need to breach your perimeter if they can compromise a trusted supplier, subcontractor, or system integration that already has access. In transport, this most commonly appears as altered delivery or collection instructions arriving through an EDI feed or customer portal that appears legitimate, invoice manipulation using a compromised supplier account, fuel card abuse where credentials have been stolen, or a subcontractor's email account used to send fraudulent instructions that your team processes without question because the sender is known and trusted.
Unusual change requests arriving through channels that are normally stable: altered delivery addresses, revised bank details for known suppliers, changed collection instructions.
New payee details appearing in accounts payable from suppliers you have an existing relationship with and whose bank details have not changed before.
Portal or EDI access events from IP addresses or times that do not match the supplier's normal pattern.
“Urgent” operational changes arriving by email only, with pressure to act before verbal confirmation is possible.
Verify out of band. Any change to bank details, delivery instructions, or access credentials received via email or portal must be confirmed by voice call to a number you hold independently, not a number provided in the request.
Freeze any suspicious accounts, API tokens, or integration credentials that may have been involved. Document what you froze and when.
Review the access logs for the integration or portal: what changed, when, and from where. This determines whether the issue is in the supplier's environment or yours.
Notify the supplier security contact if you suspect their system has been compromised. Preserve evidence for your insurer and, if personal data is involved, the ICO.
Supplier and subcontractor access register: who has access to what, when it was last reviewed, and the process for removing access when a relationship ends. Most SMEs cannot answer these questions without digging.
Least privilege for integrations: EDI feeds and API connections should have access to the specific functions they require, not broad administrative access to your planning systems.
Payment controls that treat any new payee or bank detail change as requiring out-of-band verification, regardless of the source or the urgency claimed.
Alerting on new payee creation, API token generation, and admin access grants in your finance and operations platforms.
Minimum “keep trucks moving” resilience pack.
None of these five failure modes require a sophisticated attacker. They require predictable gaps to exist: shared credentials, untested backups, no manual-mode fallback, no payment verification policy, and no supplier access register. The controls below address those gaps in order of operational impact. Building these does not eliminate the risk. It means that when one of these failure modes hits, it does not immediately become a full operational halt.
Manual mode templates and procedure
Dispatch sheets, driver call scripts, and customer update templates that work without any system access. Stored offline or printed. The question to answer now: if your TMS is unavailable from 06:00 tomorrow, what does the first hour of dispatch look like and who makes which calls? If you cannot answer that today, your manual mode does not exist as a usable procedure.
Access discipline: individual accounts and enforced MFA
No shared logins on TMS, telematics portals, or email. Every person has an individual account. MFA is enforced, not optional, on email, VPN, TMS admin, and telematics admin. This single control is the most significant differentiator between the transport businesses that contain a credential compromise quickly and those that spend weeks determining what was accessed and by whom. Shared credentials mean no audit trail and no containment boundary.
Tested backups with a documented recovery time
Not “we have backups.” Evidence of a successful restore from backup for your TMS and dispatch systems, completed within the last six months, with a documented time to recovery. The distinction matters: a backup that has never been tested is a belief, not a capability. When ransomware hits, the discovery that restore takes four days when you expected four hours turns a bad incident into a business continuity crisis. Your insurer and your customers will both ask for this evidence.
Payment fraud controls: no email-only bank detail changes
Any change to a supplier bank account, any new payee, or any payment instruction that arrives solely by email must be verified by voice call to a number you hold on file before it is processed. This one control stops the most common financial loss pattern in transport BEC incidents. The policy must be documented, communicated to finance and accounts staff, and treated as non-negotiable regardless of the urgency claimed in the request. Write the policy before you need it.
Log retention long enough to investigate
Email, VPN, TMS admin activity, telematics portal access, and endpoint security events retained long enough that when an incident is detected, the investigation window has not already closed. The most common investigation failure in transport incidents is discovering that the logs that would have identified the access vector rolled over before anyone knew there was a problem. For Microsoft 365 environments, the default Unified Audit Log retention is 90 days on standard licences. This is often shorter than the dwell time of an attacker who has been in the environment before triggering a visible incident.
These failure modes are not sophisticated. They are predictable. The controls that address them are not technically complex either: enforced MFA, tested backups, individual accounts, payment verification policy, and a documented manual-mode procedure. The gap between transport businesses that absorb an incident and those that halt for three weeks is almost always whether those five things exist and have been tested before the pressure is real.
If you want DefendVista to map these controls against your actual stack and give you a prioritised view of what to close first, a readiness call takes one hour and covers all five areas against your specific TMS, telematics, and supplier environment. Book a readiness call or call +44 (0)33 0122 4448.