A Flexible Packaging Manufacturer Meets Its Security Mandate With Files.com in Front of Azure Storage

A North American flexible packaging manufacturer produces films, laminations, pouches, and rollstock for food and consumer-goods manufacturers.

Every one of those packages starts as artwork. Before a job goes to press, packaging designs and high-resolution print data move between the manufacturer, its customers, and its print vendors. Proofs go out for approval, and corrected files come back in. That pre-print exchange is where the company's file transfer problem lived. The company needed a governed exchange that would keep every file in its own Azure scanning path, preserve sender identity, and eliminate both duplicate storage and the 24-hour wait to reach production.

Artwork by Email, and a Security Mandate No Hosted Service Could Meet

The exchange ran person-to-person. Customers and vendors sent files by email attachment or through Dropbox, one conversation at a time. There was no record of what had been sent, no way to expire access to it, and no identity behind an inbound upload. If an outside party dropped a file onto the company's systems, nothing tied that file to a named individual.

Fixing that would normally be simple: put a hosted file-sharing service in front of the outside world. At this manufacturer it was not simple, because the company's security team had drawn a hard line on where files were allowed to live. Every externally received file had to pass through Azure Defender for Cloud in the company's own Azure storage. The requirement was structural rather than a preference, and it did not bend for whatever a transfer platform happened to offer. From Azure, files sync down to the on-premises file server that the company's production systems actually use.

That architecture ruled out the standard answer. A hosted service that holds customer data in its own storage puts files outside the scanning path the mandate requires. Storing the data twice, once on a transfer platform and again in Azure, meant paying twice for print files that run to multiple gigabytes. And the raw Azure path had a flaw of its own: Azure File Sync pushed files down to the on-prem server only once every 24 hours unless a separate automation was built around it. A file a vendor delivered in the morning could sit in the cloud until the next day while a job waited on it.

So the manufacturer faced a choice nobody wanted: work around the security standard, absorb a duplicate storage bill, or accept day-old files.

What the company needed was specific. It needed an exchange layer that gave customers and vendors named, credentialed access, with per-folder permissions. It had to write every inbound file directly into the company's own Azure Files storage, where Defender would scan it under policy. It had to hold no copy of the data itself. And it had to carry inbound files onward to the on-premises server without waiting on a daily sync.

The manufacturer selected Files.com to be that front door.

Files.com in Front, the Company's Azure Storage Behind

Files.com became the governed perimeter over storage the company already owned. Using Files.com's Remote Server Mount, the IT team pointed a Files.com folder at the company's Azure Files share and pulled the existing folder structure in. The share appeared as ordinary Files.com folders, and every operation passed straight through to Azure in real time. When a customer uploaded a corrected file, the bytes landed in the company's storage, inside the scanning path the security team mandated. Files.com never held the data.

On top of that mount, the company built the governance the old exchange never had. Customers and print vendors received named, credentialed accounts, each scoped to its own root folder so an outside party saw only the folders meant for it, with folder-level permissions deciding who could read and who could write. Every login and file action landed in the Files.com audit log, so any inbound upload traced to a named individual. That attributable record was something the company wanted specifically before opening its systems to outside uploads.

Then the files moved. A Files.com Automation shuttled inbound files onward through the Azure path to the company's on-premises storage, so externally delivered print data no longer waited a day to reach the systems that used it. Proofs going the other direction traveled as Files.com Share Links whose access expired, instead of living forever in an email thread. The company's IT team stood the integration up itself.

A Governed Perimeter with No Second Copy of the Data

• Customers and print vendors deliver multi-gigabyte print files several times a day through named accounts. Every upload carries an identity and lands in the log.
• Every externally received file arrives directly in the company's own Azure storage, where Azure Defender for Cloud scans it under the security team's policy.
• Files.com stores none of the data, so the company runs a high user count against a low storage footprint. There is no second copy and no duplicate storage bill.
• Inbound files reach the on-premises server without waiting on the 24-hour interval that the raw Azure File Sync arrangement imposed.

The pattern also compounds. Bringing on the next customer or print vendor is a named account and a folder inside storage the company already governs. The architecture does not change, and the mandate is satisfied for the new party the same way it was for the first.

A New Front Door on Storage That Never Moved

Today, a print vendor with a corrected file logs into a credentialed account and drops it into a folder. The bytes land in the company's own Azure storage, pass through the scanner its security team mandated, and carry on to the on-premises server where production picks them up. Nobody at the company forwards an attachment, and nobody wonders afterward who sent what.

The contradiction the manufacturer started with turned out not to be one. A mandate that every file pass through your own storage and your own scanner does not rule out a managed transfer platform. With Files.com, the exchange layer sits in front of the storage instead of replacing it, and the security team's line never had to move.