Finning CAT Turns a Mining Truck's First Failed Login Into Its Own Files.com Account

Finning International is the world's largest Caterpillar dealer. Its 13,000 employees sell, rent, and service Cat equipment for mining and construction customers across Western Canada, South America, and the UK and Ireland, and the company has helped stand up some of the largest autonomous haul fleets in the world.

Part of that service is condition monitoring. More than 1,900 connected trucks across the three regions upload sensor data over FTP into Finning's Files.com site: fuel consumption, failure codes, warning codes. Finning processes that data and turns it into the maintenance and repair decisions it delivers to its mining customers.

The machines sending that data do not belong to Finning, and they do not sit on Finning's premises. They belong to customers, they work at mine sites around the world, and they are configured by whichever technician happens to have the machine in the bay. A new truck can come online and attempt to connect before anyone at Finning's head office knows it exists. Every one of those machines needs credentials, and that is where the trouble was.

One Password for Four Hundred Trucks

For years, the answer was a shared account. More than 400 trucks connected with the same credentials, because a single password was the only thing Finning could reliably put into every technician's hands.

The cost showed up at fleet scale. Field teams kept adding trucks, and every addition was a chance to take the whole fleet down.

“From time to time they would enter the password wrong or copy and paste with space at the end. This causes the entire fleet to stop sending data.”

One trailing space in a pasted password was enough to trip the automatic lockout on repeated bad logins, and every truck on the shared account went dark at once.

Per-truck accounts were the obvious fix. Getting there was the problem.

A Logistics Problem, Not a Technical One

The conventional way to provision an account is that someone requests it, IT creates it, and credentials come back. That sequence fails at a mine site.

The logistics look like this. Credentials get programmed into a truck by hand, by a technician Finning often cannot identify in advance, during the short window while the machine is out of service. A haul truck is a high-value asset that needs to return to work quickly. The technician may have no access to Finning's internal systems, and no time to wait on a ticket even if they did. Every extra step in the chain is another point where the onboarding fails and the truck leaves the bay silent.

“We don't have control over, or necessarily even know of, the equipment that is out there. A new truck could be onboarded and attempt to connect and we may not even know it exists until after the fact.”

So the fix had to work backwards from the field. The right credentials had to be knowable before anyone asked for them. The account had to create itself, with no request, no approval, and no human in the loop. And it had to verify that a machine claiming a serial number was a real machine. Finning built that provisioning layer against Files.com, using the platform's FTP action logs and API as the trigger.

Serial-Based Credentials, and an Account That Creates Itself

Finning inverted the flow. Instead of creating an account and then distributing credentials, they tied the credentials to each machine and let the account follow.

Every machine's credentials are based on its serial number, following a convention in the field documentation technicians already use. A technician programs those credentials into the truck and closes the panel. The truck attempts to connect to Files.com and fails. That failure is the point.

Finning built a service to watch the Files.com FTP action logs through the API. When a failed login matched the credential convention, the service extracted the serial number and validated it against Finning's equipment database. If everything lined up, the service created the truck's account through the same Files.com API. On its next attempt, the truck connected and data started flowing. Failure-then-success was the normal onboarding path, by design.

The whole loop now closes within 5 to 10 minutes of the technician's work. Nobody requests anything, and nobody approves anything. The truck announces itself, Files.com records the attempt, and Finning's service does the rest.

Provisioned Before the Truck Leaves the Bay

With the provisioning service in production, Finning replaced an onboarding path built on a shared password and service-desk requests with one the field triggers implicitly.

• A truck has its own working account within 5 to 10 minutes of a technician programming it, inside the same service window the credential work already occupies. No return visit, no waiting on a ticket, no extra hour in the bay.
• A password mistake now locks out one machine, not a fleet. The failure that once stopped every truck's data at the same moment cannot reach past a single serial number.
• A machine head office has never heard of can onboard itself. New equipment joins at the customer's pace, and Finning finds out when the data arrives, which is exactly how they designed it.
• The next truck adds no new administrative step. The credential convention, the logs, and the API do the same work for each machine, which is what makes a per-truck account model workable across three regions at all.

What Changed at the Mine Site

Today, nothing about the technician's job has changed. They program credentials into a machine in a bay, the same as they always did. Everything behind that act has changed. An onboarding process that would otherwise have meant tickets and waiting now requires nothing else of anyone. Files.com records the truck's first knock at the door, Finning's service confirms the machine is real, and by the time the truck is back to hauling, it has an identity of its own.

The lesson travels beyond mining. When you cannot control who configures your devices, or when, or where, and you may not know a device exists until it speaks, the device's own first login can be the provisioning request. Serial-based credentials and a log-driven check against a system of record turn account creation into something the field does implicitly, and the Files.com logs and API are what let Finning run that as a production pattern instead of a wish.