FlightSafety Moves Oversized, Confidential Aviation Documents Beyond Email With Files.com

FlightSafety International trains pilots, maintenance technicians, and dispatchers for airlines, business operators, governments, and militaries. Professionals from more than 170 countries train with FlightSafety at learning centers on six continents. The company also designs and manufactures flight simulators and training devices.

All of that work lives under regulatory approval. FlightSafety's training devices are qualified by the FAA, EASA, and other civil aviation authorities worldwide, and the operators it trains carry compliance obligations of their own. Documentation flows constantly between FlightSafety and the outside world: aviation authorities, airlines, simulator vendors, and individual training operators all submit documents and receive them back. What each of those parties submits is confidential from every other one. With files too large for email and anonymous sharing off limits, FlightSafety needed an exchange that authenticated each party and confined it to its own folder. It built that exchange on Files.com.

Too Large for Email, Too Confidential for a Shared Folder

FlightSafety's regulatory affairs team, which handles FAA and EASA compliance work, receives confidential documentation from hundreds of external counterparties. Email failed that workload twice. It failed on size: single files in this exchange ran to 26 GB as early as 2015, far past what any mail system will carry. And it failed on policy: FlightSafety's security team holds that unencrypted email should not carry personally identifiable information. For a large class of submissions—the compliance documents themselves—an operator had no safe way to get a file to FlightSafety at all.

The obvious alternatives failed just as hard. A shared drop folder was unacceptable, because each operator's submissions are confidential from every other operator; no external party could ever be allowed into a general folder. Anonymous file links were ruled out flatly. A link that anyone holding it can open is a link anyone in the world can open, and FlightSafety's security team would not send one.

The resulting requirements were exacting. Every external party needed an authenticated identity. Every identity needed to be scoped to exactly one folder. Access needed to expire on a schedule rather than linger. And the channel had to serve a community running from national aviation authorities down to individual training operators, reachable from a browser with nothing to install.

A Login and a Folder for Every Counterparty

On Files.com, every external counterparty was given its own account and its own folder. Files.com's folder-level permissions scoped each account to that folder, with tighter subfolder restrictions where a party needed even less. An operator who logs in sees one folder: theirs. That is not a procedure anyone follows. It is all the account can reach.

FlightSafety then closed the anonymous path entirely by disabling share links across the site. No file on the site moves through a public link; every upload and every download is tied to an authenticated user. External accounts were created with expiration dates, so a counterparty's access lapses on schedule and gets re-authorized when the relationship continues, instead of quietly surviving indefinitely.

The community connects in whichever way suits it. Operators use the web interface, on pages carrying FlightSafety's own branding, with nothing to install. Internal systems and technical users connect over SFTP. Both paths land in the same permission structure.

Risk Off Email, at the Scale of a Thousand Accounts

With the Files.com exchange in place, FlightSafety created a secure route for the submissions email could not handle. The model has scaled to roughly a thousand external and internal accounts and run continuously for more than a decade. It has also generalized across the business: workstreams from FAA regulatory work to defense training programs to vendor exchange run on the same platform, under one security team.

• Submissions that email could never move, including single files of 26 GB, reach regulatory affairs through a channel any operator can use from a browser.
• Documents carrying personally identifiable information have a path that avoids unencrypted email: exchanges run under authenticated accounts over encrypted connections.
• Per-operator confidentiality is enforced by the permission structure rather than by procedure: no operator can reach, or even see, another operator's folder.
• External access expires on a schedule and is re-authorized deliberately, so access does not persist indefinitely without review.

The pattern also compounds. Onboarding the next counterparty is an account and a folder, the same at the tenth operator as at the five-hundredth.

Confidentiality as Architecture

Today, an operator with compliance documentation to submit opens a FlightSafety-branded page, signs in, and sees exactly one folder: their own. The file that once had no safe way to travel, too large for email and too sensitive to send unencrypted, now moves through the only door that operator has, into the only folder that operator can reach.

That is what Files.com gave FlightSafety: one authenticated identity per counterparty, one folder per identity, and no anonymous path anywhere on the site. When every counterparty's submissions must stay hidden from every other counterparty, that is what confidentiality has to be. Not a rule people remember, but a structure the platform enforces.