DNV Secured Plain-FTP Datalogger Ingest with a No-Read Files.com Drop Point

DNV is the independent assurance and risk-management company headquartered in Høvik, Norway, with 15,000 experts working in more than 100 countries across maritime classification, energy, and certification. In wind power it is a technical authority of long standing: DNV helped develop the IEC standards that turbine power performance testing is run against.

In Australia and New Zealand, part of that work belongs to a seven-person measurements section inside Energy Analytics and Measurements. The section tests wind-turbine performance and monitors renewable-energy resources with met masts, lidar, and solar stations. It owns the instruments, deploys them on customer sites, and runs the data pipeline that comes off them. When a wind farm owner needs a turbine's power curve verified against the supplier's warranty, the verification runs on data those instruments collected.

That proposition is what made the problem inevitable. DNV's own instruments sit on other companies' remote sites, each producing a file every day. The business only works if those files come home, and if the customer who paid for the campaign can get at them.

Rugged Instruments, an Old Protocol, and Nowhere for the Data to Land

The dataloggers are an old industrial breed, built to survive years on a met mast or a turbine rather than to keep up with modern transport security.

“We still have to use plain FTP for a lot of devices because they're old industrial PLC type. They can do it, but it can be an absolute nightmare to get them to actually work.”

So the fleet speaks plain FTP, and that was not going to change. Neither was anything else about a deployed device. Updating a logger's configuration by hand means an expensive trip to a remote site, and the campaigns the fleet serves can run for as long as ten years. Whatever address and credentials a logger carried on the day it was commissioned had to stay valid for as much as a decade.

And in 2017 there was nowhere for any of it to go. DNV had a fleet of remote dataloggers generating daily data and no repository to receive it, and no repository through which its own customers could reach their data and reports.

The shape of the fleet made the obvious designs unsafe. The loggers serve campaigns for different customers, but the section needed one logger program with identical login parameters for every device, regardless of whose campaign it served. One program means one credential, held by every device in the field, sent over an unencrypted protocol. Backwell's design assumption was blunt: treat the logger account as unsecured. The answer would have to let every logger write without allowing that shared credential to list or read what was already there.

A Clearing House the Loggers Can Write To but Never Read

What the section needed was specific. An endpoint that accepts plain FTP from any device, with one program and one login for the whole fleet. Tenants kept invisible to each other on a shared drop point. A credential that, even if exposed, cannot read directory contents. An address stable enough to outlast a ten-year campaign. A web interface where customers collect their own data and reports. And the data's permanent home on DNV's own file server in Australia.

DNV selected Files.com to be that endpoint, and the section configured the whole design itself.

The isolation comes from Files.com's per-folder permission model. Every logger writes into a single repository directory through a handful of shared machine accounts, one per equipment class, and those accounts hold write and delete permission with no read. In normal operation, DNV's downstream script pulls each file and deletes it from Files.com. The ingest account cannot list the directory, cannot open a file, and cannot see that any other customer's data exists. Even exposed, the credential does not expose stored files.

The site behaves as a clearing house rather than storage. A script on DNV's Australian file server pulls everything off the site on a half-hourly cycle, and an SCP step fans the files out into each customer's project directories. A file rests on Files.com for thirty minutes at most; its permanent home is DNV's own infrastructure in Australia. The problem was governed delivery from hardware nobody could touch again.

The same site is DNV's customer face. Customers log in through the Files.com web interface, collect their data and reports, and log out. The service also accepts SCADA data from third parties and feeds a repository used by other DNV sections. Downstream, the collected logger data feeds DNV's power performance analysis against turbine-supplier warranty requirements.

Site credentials were embedded into the device fleet in the field, once, at deployment. Nothing since has required going back.

One Program, No Field Visits, and a Five-Minute Repair

The design the section stood up in 2017 was still running unchanged in its essentials in 2024, and what it removed is a whole category of work and risk.

• Commissioning a logger for any campaign, for any customer, means loading the same program with the same login. There is no per-customer setup on the device, and no path by which one customer can reach another's data.
• The pipeline never sends anyone into the field. Credentials embedded at deployment stay valid for the life of a campaign, and the expensive remote-site trip that a configuration change would otherwise cost is work nobody does.
• DNV's internal infrastructure changes without the fleet noticing. When the entire Australian file server was re-rooted over a weekend, Backwell set aside half a day to repair the pipeline. It took five minutes: a find-and-replace on one path in one script, while every logger in the field kept delivering to the same address it always had.
• The section runs the whole operation: roughly 80 devices delivering daily, customer self-service through the web interface, and the analytical work the data feeds.

The immediate result was a fleet with somewhere secure to deliver. The compounding one is architectural: another device is another copy of the same program pointed at the same address, and another campaign is another project directory downstream. Nothing in the pipeline is bespoke to any customer or any device.

Governing the Drop Point Instead of Upgrading the Fleet

The loggers themselves have not become one bit more modern since 2017. They still speak plain FTP, the same as the day they were commissioned. What changed is everything around them. The fleet's shared credentials can deposit files but cannot list or read anything already there, limiting what exposure over the old protocol could reveal. The address the fleet delivers to has not moved in seven years, so it no longer matters that changing it would mean driving to a remote site. An engineer commissions a logger once, and its data arrives every day for as long as the mast stands; the customer logs in to Files.com and collects it.

DNV did not modernize its hardware to govern its data. It governed the Files.com drop point the hardware delivers to, and the hardware never had to change.