A demonstrated method for identifying ELDs that violate the federal output-file specification — applied to the public ELD registry and applicable to roadside transfer data already received by FMCSA.
ELD fraud does not require new data to detect. The federal ELD specification already makes a compliant output file tamper-evident, and FMCSA already receives these files through roadside data transfers. What is missing is a verification step. We built a tool that performs that step — checking output-file integrity, not just format — and that flags high-risk devices in the public registry. Both methods run on information FMCSA already holds. Most could be adopted without new legislation.
ELDs are self-certified: a manufacturer attests compliance and is listed in the registry; FMCSA does not independently test the device's code or behavior. FMCSA publishes an official File Validator, but it checks format conformance only. A device that silently overwrites a driver's record — destroying the original instead of preserving it — produces a perfectly well-formatted file. It passes validation. The fraud is invisible to the one automated check in the pipeline.
A small, dependency-free application with two detection methods and a self-test that proves the detector is sound.
Self-test: the tool generates one spec-compliant output file (which it correctly passes, 100/100) and six files each altered by a known tampering technique (which it correctly fails, each caught by the rule that targets it). 7 of 7 cases pass — the detector neither misses tampering nor flags clean files.
Given an ELD output file, the tool parses the event records and checks the integrity guarantees the format validator ignores. Each check cites the specification section it enforces:
| Check | What it catches | Spec |
|---|---|---|
| Retained original on edit | A record edited in place with no preserved original (the clean-overwrite backdoor) | §4.4.4.2(a) |
| Automatic-driving immutability | Engine-recorded driving converted to off-duty / sleeper | §4.3.2.8.2 |
| Driving-time not shortened | Auto-recorded drive time reduced by edit | §4.3.2.8.2(b) |
| Event-sequence continuity | Deleted records (gaps in the append-only log) | §4.4.4.2.1 |
| Check-value integrity | Records altered after the device signed them; unsigned files | §4.4.5.1 |
| Engine-data (ECM) plausibility | "Driving" with no odometer/engine movement (fabricated / GPS-only) | §4.3.1.4–5 |
Fraudulent ELDs cluster around a recognizable profile. Scoring the public registry on these publicly verifiable signals surfaces where to look first. Across 827 registered devices:
| Signal (public-data join) | Devices | Why it matters |
|---|---|---|
| Registered from a residential address | 177 | Cottage operation, not a vendor with a compliance lab |
| Free-webmail registrant contact | 102 | Most consistent marker across already-revoked devices |
| Shares email/address with a revoked ELD | 55 | Re-registration of a removed operation under a new brand ("whack-a-mole") |
| Generic white-label hardware | 45 | Skinned app over commodity hardware, not original engineering |
| Manufacturer is also a motor carrier | 6 | The regulated entity building its own oversight device — structural conflict |
Each signal is an automatable join across the ELD Registered Device List, the ELD Revoked List, and the FMCSA QCMobile carrier-census API — all public. The manufacturer-is-carrier link is found by cross-referencing the registry against the carrier census, a join FMCSA is uniquely positioned to run across its full dataset.
| Action | Effort |
|---|---|
| Run integrity checks on eRODS transfers. Apply Method 1 to output files already received; flag devices with systematic violations. A software step on existing data. | No rulemaking |
| Score the registry continuously. Apply Method 2 to the registry + revoked list + carrier census to prioritize review and detect re-registration of revoked operations. | No rulemaking |
| Require a conformance test at registration. Replace pure self-attestation with submitted sample output files that must pass integrity validation before listing. | Process / rulemaking |
| Capture the carrier↔device link. Have carriers declare their ELD (data largely collected already), creating the device-to-fleet map that today does not exist. | Process / rulemaking |
| Strengthen the check value to a digital signature. The current XOR/rotate check value is tamper-evident but not tamper-proof; a cryptographic signature would make forgery infeasible. | Spec amendment |
The registry contains app-based ELDs registered from a home address, under a free-webmail contact, whose registrant also appears in the carrier census as an active or former motor carrier — i.e., a regulated carrier publishing the device meant to police carriers. Separately, dozens of currently-registered devices share a contact email or address with a device FMCSA has already revoked. Neither pattern is proof of wrongdoing on its own, but both are precisely the kind of lead a verification process should surface for review. Specific records and their public-record citations are available on request.
A verification capability for ELD output files — applied to the data FMCSA already receives — would convert the agency's posture from trusting self-certified compliance to checking it, using methods demonstrated to work and data already in hand. We are glad to share the implementation, the rule set with its CFR citations, and the underlying analysis with FMCSA, the DOT Office of Inspector General, or oversight staff.