Why this matters
- The file server never lost the security argument. It lost the convenience argument, and it lost it on phones.
- Moving a share into a cloud sync service changes three things that are hard to reverse: who holds the encryption keys, whose courts can compel disclosure, and how many copies of each document exist.
- Staying on-prem only counts as more secure if you also solve mobile access. If you do not, staff route around the share with mailed attachments, personal cloud drives and app store SMB clients, and you get both sets of risks at once.
- On-prem done properly means Kerberos against your own domain controllers, SMB signing and encryption, AD groups as the single source of truth, and it keeps working when the internet does not.
- Hypergate Files puts those shares on managed Android and iOS with native Kerberos SSO. It needs a network path to the share, and it adds no second credential store.
Ask an IT admin why the department file share moved to a cloud service, and the answer is almost never that it was safer there. The answer is that people needed the files on a phone in a warehouse aisle or a van or a ward, the SMB share could not do that, and something had to give.
Afterwards the migration usually gets written up as a security upgrade. It is really a trade. You swap a set of risks you own for a set of risks somebody else owns, and you accept a lot more copies of your data in exchange for convenience on mobile. Sometimes that trade is worth making. It is worth making deliberately.
What on-premise actually buys you
Four things, and all of them are about custody rather than location.
The first is key custody. On your own file server the keys never leave your estate. Cloud providers do offer customer-managed keys, and that is genuinely better than nothing, but in most deployments the provider still handles plaintext in memory to index, preview and search your documents. Check what your own key management setup really does before claiming otherwise.
The second is jurisdiction. A US-headquartered provider can be served under the CLOUD Act whichever region the data sits in, which is why „our data centre is in Frankfurt“ does not settle the question for a regulated Swiss, German or EU organisation. Storage in your own building has one legal address, and it is yours.
Third, blast radius. A breach at a large file sync provider is a breach of every tenant behind that control plane, while a breach of your file server is a breach of your file server. Neither is a good afternoon, but only one of them scales without your help.
Fourth, and this is the one that quietly decides the whole argument in some industries: on-prem keeps working with no internet. Manufacturing lines, hospitals, ships and defence sites need file access when the WAN is down or was never built. Cloud sync has no answer for that.
The mobile gap is the whole problem
Windows has had a Kerberos client since Windows 2000. A domain-joined laptop opens \\fileserver\finance, the OS fetches a service ticket from a domain controller, the share opens, and nobody types a password. Intranet and web apps behave the same way. File shares work on the desktop because the operating system does the authentication for them.
Android has no Kerberos client, and neither does the average mobile file browser. A phone therefore cannot do what the laptop does, which leaves three options: put a gateway in front of the share, move the files to a cloud service, or let people improvise. Plenty of organisations end up with a mix of the last two without ever deciding to.
Shadow IT is where the security actually goes
The weak point in on-prem file sharing is rarely the file server. It is the workaround.
A technician needs a wiring diagram on site, so the drawing goes to a personal mail address. A nurse needs a protocol PDF, so it lands in a consumer file app that caches it unencrypted and syncs it to a vendor nobody vetted. A field engineer installs a free SMB browser from the app store, types domain credentials into it, and leaves an AD password sitting in an app with no security review, no MDM control and no way to revoke it.
That last case is worse than a leaked document, because what leaked is a reusable domain credential. The file server’s audit log shows nothing odd about any of it: a legitimate user opened a legitimate file, exactly as expected.
All three are symptoms of the same unmet requirement. Meet the requirement and the workarounds stop being attractive.
What on-prem has to get right to earn the claim
On-premise is not a security control by itself. A file server reachable over NTLM and unsigned SMB is not safer than a well-run cloud tenant. To make the claim honestly you need:
- Kerberos rather than NTLM. Microsoft is phasing NTLM out, and the relay and pass-the-hash families are the reason. Kerberos is phishing-resistant by design, and your DCs already speak it.
- Certificates instead of passwords where you can get them. PKINIT lets a device obtain a Kerberos ticket with a certificate, so there is no password on the device to phish.
- SMB 3 signing and encryption switched on, SMB 1 gone. Both are policy settings you already control.
- AD groups as the only authorisation source, so there is one place to revoke access, one place to audit it, and no separate per-app permission model drifting away from what HR knows.
- A sanctioned mobile path, for the reasons in the previous section.
How Hypergate Files can help you out
Hypergate Files is a managed file browser for SMB shares on Android and iOS. It authenticates with native Kerberos against the domain controllers you already run, using a certificate or a password, so file access on a phone works the way it works on a domain-joined laptop. AD groups keep deciding who sees what. It deploys as a managed app with managed configuration through Intune, Ivanti, SOTI, Workspace ONE, Knox Manage or any Android Enterprise EMM.
Two caveats, stated plainly. Files needs a network path to the share, which in practice means a VPN or equivalent tunnel into your network. And it is a browser for your existing shares, not an EFSS platform: if what you need is a public download link for a customer, this is the wrong tool.
What you get for those constraints is that nothing new joins the trust chain. Your files stay on your file server, your DCs keep issuing the tickets, and there is no second directory to keep in sync.
| Cloud EFSS / sync and share | Gateway or container to on-prem | Native Kerberos client on managed device | |
|---|---|---|---|
| Where the files live | Provider tenant, plus device copies | Your file server | Your file server |
| Authentication to the share | Provider identity, often SAML | Gateway service account | User’s own Kerberos ticket from your DC |
| Second credential store to manage | Yes | Usually | No |
| Jurisdiction | Provider’s | Yours | Yours |
| Works with no internet | No | Depends on the gateway | Yes |
| Network requirement | Internet | Published gateway endpoint | VPN or tunnel to the share |
| External sharing links | Yes | Sometimes | No |
The short version
On-premise file sharing still matters because key custody, jurisdiction and blast radius follow the data and the authentication, and those are expensive decisions to reverse. It stops mattering the day your own staff cannot reach the files from the device in their hand, because from then on the traffic goes somewhere you are not watching.
So the useful question is not cloud or on-prem. It is whether your on-prem shares are reachable from managed mobile devices without a second identity system and without a domain password sitting in an app you do not control. If they are, the security case for staying on-prem holds. If they are not, you are already losing files, and the file server’s audit log is the last place that will tell you.
A timing note for anyone reading this with a renewal on the desk: Acronis Cyber Files reaches end of life at the end of 2026. If that product is what currently bridges your shares to mobile, the decision has a date on it.
Rolling out cloud Kerberos trust?
Your Windows fleet gets passwordless Kerberos. Hypergate Authenticator brings the same silent, passwordless SSO to Android and iOS, and Hypergate Files puts your SMB shares on those devices, all against the same domain controllers, deployed through the EMM you already run.
