What’s changed?

• Added a stricter pinned-key TLS mode, designed to work in conjunction with Syncplify Server! v8.1+ (which is itself scheduled to be released later today); when enabled R2FS! will refuse to connect to Server! versions prior to v8.1 to prevent the possible adoption of a more relaxed TLS enforcement
  NOTE: even with this setting disables, when R2FS! v2.2+ connects to a Server! v8.1+ the stricter TLS mode is always guaranteed to be enforced

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Up till now, we simply didn’t need one. We sold software you downloaded and ran yourself. Your files sat on your servers. Your users lived in your directory. Your logs stayed on your disk. We had nothing of yours to protect, so there was very little for an auditor to look at, and a report confirming that we held no customer data would have been an expensive way to state the obvious.

But we’re about to launch SFTP.cloud now, and that makes everything more interesting. It is a service we operate, which means we now have uptime to be responsible for, access to our own systems to control, people to vet, and changes to manage. Those are fair questions and customers must be given the answers without having to ask them.

Here’s the wrinkle, and we rather like it: we still don’t have your files. SFTP.cloud is built so that customer data stays in customer storage, and so that we never hold the credentials to reach it. A good portion of what a SOC 2 report usually existsfor still doesn’t apply to us. What’s left is how we run the service, and that is exactly the part we want examined.

Now the part we’re less polite about

We have a low opinion of compliance as an idea. It shares more than a first syllable with complacency. A framework is an easy thing to perform rather than practice, and a certificate has never once stopped a vulnerability from shipping.

We started this because the work has value on its own. Writing down how you actually do things, and then finding all the places where you don’t, is useful whether or not somebody checks afterwards. Access reviews you can’t quietly skip. Change management that leaves a trail. Onboarding and offboarding that run the same way every time instead of the way whoever was free that afternoon remembered it.

We have done most of this for years. Doing it in a standardized form that a third party can inspect is a different beat altogether, and it can make us better.

If the certificate turns out to be the least interesting thing we get out of this, that will be the right outcome.

What happens next

The Type 2 observation window runs for months. We’ll publish the report when we have it, and we’ll write about what we learned, including the parts that were uncomfortable (if any).

Until then, nothing about how SFTP.cloud is built depends on any of this. Your files are still yours, still in your storage, still reachable only with credentials we never see.

“Zero trust” appears on almost every MFT website nowadays. Usually right next to a padlock icon, a compliance badge, and a sentence about encryption in-transit and at-rest.

Then you read the architecture page, and realize the files live on their servers, or they require the credentials and an in-path to access your storage. LOL! 😂

Both things cannot be simultaneously true: Zero Trust is not a “feature”, it’s an architectural property of the system, it’s either built-in by design, or it doesn’t exist.

What zero trust actually asks of an architecture

Strip away all the marketing blah-blah, and the requirement becomes clear: never grant standing trust + verify every request + assume any component can be compromised. Bottom line: design the entire platform so that when one of its parts falls, the damage stops there (aka, minimize the blast radius).

That last part is the one this industry keeps pretending it doesn’t exist. Zero trust is not primarily about how strong your authentication is, it’s about what an attacker gets when an attacker skips through a crack anyway. If the answer is “your files”, the model has failed, no matter how many authentication factors guarded the door.

So the honest test for any managed cloud SFTP service is a single question: if someone (a hacker, a rogue AI agent, you name it!) fully compromised the vendor’s platform tomorrow, what would they walk away with?

Where the trust actually sits in most of this category

There are two common answers today, and neither one survives the question.

The vendor holds your files. They sit on the vendor’s infrastructure, sometimes only during a transfer, often for much (much!) longer. Everything about your security posture now depends on that vendor’s operational discipline being perfect, permanently. You have granted a standing trust relationship to an environment you cannot inspect, patch, monitor, or contain. That is an implicit trust zone. It is precisely the thing zero trust was designed to eliminate.

The vendor holds your storage credentials. This one somehow manages to “feel safer” (the mighty power of marketing?) but that’s precisely why it’s worth being extra careful about it. Your files stay in your own S3, GCS, or Azure Blob storage. The vendor simply holds an access key, an IAM role, or a service account so the platform can reach in and fetch them… Hum, wait, what? 🤔

Look at what was actually granted! A credential that can read your storage is functionally the same as holding the storage, only with a minuscule built-in delay. Compromise the platform, extract the credential (often already held in RAM, unencrypted and trusted, for speed) and the outcome is identically catastrophic.

Both models come to the same place: they ask you to extend permanent trust to an environment outside your control, and they call the result “zero trust” because the traffic is encrypted.

Encryption is not the same as zero trust

Encryption protects data from parties who are not holding the keys, it stops nothing against a party who does.

This is why “encrypted in transit and at-rest” is a weak claim in this category and always has been. A secret held by an endpoint cannot defend against that endpoint’s own compromise.

So, a service can be fully encrypted, competently run, compliant with several frameworks and regulations, and still fail every meaningful zero trust test.

What passing the test would look like

If the standard is “compromising the vendor yields nothing”, then the architecture has to satisfy way stricter conditions than the ones described above.

• Customer files must never reside on the vendor’s infrastructure. Not in transit staging, not in a cache, not briefly, not ever.

• The vendor must never hold a credential set that grants access to customer storage. Not scoped, not rotated, not vaulted. It simply has to be not-held.

The path to storage must be opened from the customer side, outwards to the SaaS MFT side, so nothing in the vendor’s platform can initiate a reach inward even if it wanted to.

Storage is wherever the customer already keeps it, cloud or on-premises, because a design that only works when the customer’s data is in someone else’s cloud has the exact problem we are trying to avoid built into its design.

Those conditions are demanding. They also rule out most of what is currently sold as zero trust managed file transfer. And that is the whole point.

Why we keep coming back to this

This level of True Zero Trust is the design goal we set for SFTP.cloud before we even wrote its first line of code, and it is the reason the architecture looks so unusual. We do not hold your files. We do not hold keys into your storage. We never needed a way to reach into your network, so we did not build one.

So, when you evaluate your next MFT solution, ask yourself what an attacker gets when the platform falls. Then decide whether the words on the homepage matched the answer.

We are building SFTP.cloud to give a boring answer to that question. Early access is open to the first 100 people who want in: reserve your spot at sftp.cloud. Not ready yet? Subscribe to this blog and we will keep you posted.

What’s changed?

• Identity verification during HA-JOIN is now mutual and bidirectional

• Increased password hashing rounds to the levels required for full FIPS 140-3 compliance (and all existing hashes are automatically upgraded at next login with zero administrative burden)

• Fixed a bug that allowed a SuperAdmin to create a password-less SuperAdmin account (the password-less SA would be dead-on-arrival though, as password-less SuperAdmin logins are always forbidden by the API, so this does not constitute a widening of the software’s security posture)

• Strengthened TOTP replay prevention in all 2FA/MFA paths, now even cross-node when the software runs in high-availability (HA) deployments

• Improved the TOTP general user experience (UX), now featuring recovery codes (shown only once during enrollment)

• Added the ability for each individual user to revoke “trusted devices” (specifically for the TOTP authentication path)

• WebClient! now properly honors the “force change password” and “force enroll in MFA” settings when an Admin sets them for a specific user account

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Today, less talk. We want to show you something.

These are the first screenshots of SFTP.cloud we share publicly. It’s early. This is an alpha, closer to a minimum viable product than a finished one, and plenty will change before launch. But it’s real, it runs, and the pieces you’ve been reading about are on screen and working.

The Portal: your site, at a glance

This is where you’ll manage a site. Connection addresses for every protocol your people might use (SFTP, FTPS, web), users, storage, billing, all in one place. There’s even a bring-your-own-domain option.

And look at the “Service status” panel for a second. Notice it’s split in two. On one side, our platform, the parts we run and stand behind with an SLA. On the other, your connectors, running on your network, on your terms. That split isn’t a UI accident. It’s the whole idea, showing up in the interface: the parts we operate and the parts that stay entirely yours are, and always will be, separate things.

The Connector: where your storage stays yours

This is the other half. The connector runs next to your storage, wherever that happens to be, behind your own firewall with no open inbound ports, and links up to your site.

The panel at the top says “Uplink to your site,” and the word uplink is doing real work there. The connection goes one direction: from your storage, outward. We’ll have a lot more to say about why that matters closer to launch. For now, we’ll just let it sit there, connected, quietly not requiring a single thing to reach in.

This is the part where we ask you to be patient

There’s a real product behind these screens now, and it’s improving every week. We’re not putting a date on the table yet, and we’re deliberately not walking through some of the finest details of the architecture (for now).

What we can tell you is that everything we’ve been claiming in these posts (files that never live in our cloud, storage that stays entirely under your control, nothing reaching inward through your firewall) isn’t a roadmap wish or a marketing claim. It’s what you’re looking at.

Want to see it for real before anyone else? We’re opening early access to the first 100 people who reserve a spot now and get 2 months completely free when the platform launches: claim your spot at SFTP.cloud. Not ready yet? Subscribe to this blog and we’ll bring the next news straight to you.

What’s changed?

• Fixed a bug that only affected R2FS!-type Virtual File Systems (VFSs) and prevented the Content-Disposition header from being properly formatted upon downloading files from the WebClient! UI. Special thanks to our friend Jeff, not only for finding and reporting this, but also for helping us reproduce the issue in our own systems, which ultimately made the fix nearly trivial.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

It’s for a bug we fixed in 2020. In forty-eight hours.

Pull up a chair, because the six years in between are the interesting part.

The timeline

2020 — A security researcher finds an unquoted service path in Syncplify.me Server! 5.0.37 and emails us about it. He is, for the record, extremely decent about the whole thing.

2020, plus about 48 hours — We ship the fix. We find no evidence any customer was affected. And we release it as v5.1.0 rather than 5.0.38, because we wanted a version number that cut the psychological cord with the affected build. Nobody should have to squint at a patch level to know whether they’re clear.

2020, shortly after — The finding goes public on Exploit-DB as entry 49009. No secret, no embargo, no quiet burial. Anyone could read it. Nobody assigned it a CVE number.

Six years pass. Nothing happens. The bug stays fixed. The record stays empty. Not a single customer has ever contacted us to report this bug being exploited. Not one.

16 May 2026 — VulnCheck, a CVE Numbering Authority that assigns identifiers to historically unnumbered vulnerabilities, files CVE-2020-37230. Same bug. Same version. Six years later.

And that is how a company with a clean vulnerability record for thirteen years acquires a HIGH-severity CVE overnight, for something that has not existed in a shipping build since 2020.

The facts, up front, no burying

CVE CVE-2020-37230
Product Syncplify.me Server! 5.0.37
Component the `SMWebRestServicev5` service
Class unquoted service path — CWE-428
CVSS 4.08.5 HIGH
CVSS 3.17.8 HIGH
Attack vector Local
Fixed in v5.1.0
Assigned by VulnCheck, 16 May 2026
NVD record CVE-2020-37230

If you are somehow still running 5.0.37 six years later, please update to the most recent version of our software. If you’re on anything 5.1.0 or later, you were never exposed to this in the first place.

What it actually is (and isn’t)

An unquoted service path is one of the oldest and least glamorous bugs on Windows. When a service’s binary path contains spaces and isn’t wrapped in quotes, the service control manager tries several interpretations of that path before finding the right one. Someone who can write an executable into one of the earlier interpretations gets their code executed instead of ours, with LocalSystem privileges, the next time the service starts.

To exploit it, an attacker needs to already be on the machine, already hold write access to a privileged directory, and then needs to wait for a restart.

OK, that is not “nothing”, which is why the fix took two days rather than two sprints. But be precise about what it is not. Not remotely exploitable. Not pre-authentication. Not network-reachable. Nobody can be scanning the internet for this. It does not let anyone touch your files from the outside.

About that 8.5 score

You’ll notice the score is HIGH, and you may reasonably wonder how a bug requiring a local foothold lands at 8.5.

CVSS scores impact after exploitation, and escalation to LocalSystem scores about as badly as anything can. The difficulty lives in the AV:L (Attack Vector: Local) which is exactly the part that evaporates the moment the number gets pasted into a risk register.

We could spend three paragraphs arguing that number down. We’re not going to, for a specific reason.

We spend a fair amount of time pointing out that when a vendor acts as its own CVE Numbering Authority, it gets to score its own bugs, and that some vendors’ own scores land at 3.5 LOW for bugs NIST rates 9.8 CRITICAL. That’s a fair criticism. It stops being fair the instant we run it in reverse on ourselves.

So: 8.5 HIGH. That’s the number. It’s on the record and we’re not litigating it. Argue the class if you want to argue something. We’ve given you everything above to do that.

The genuinely interesting part

Here’s what this episode should actually tell you, and it’s bigger than us.

The CVE system is not a real-time feed. It’s a lagging, incomplete, retroactively-edited index.

A vulnerability existed. It was found, reported, fixed in 48 hours, and published on Exploit-DB all the way back in 2020. The CVE arrived in 2026. For six years, the public record of that bug was: nothing. And then one day, without any change to any shipping software anywhere, it was a HIGH.

Three things follow, and we’d rather you took all three than just the flattering one:

One. “No recent CVEs” means much less than people think. A quiet record can mean a solid product. It can also mean nobody has gotten around to the paperwork. Those look identical from outside.

Two. The same is true of everybody else. Some of our competitors’ records are probably understated for exactly the reason ours was. We’re not going to pretend otherwise to win an argument. If VulnCheck’s backfill program reaches further, several vendors in this category are going to have an interesting quarter.

Three. Which is why you should read the record, not the count. One local priv-esc fixed in two days is not the same animal as an unauthenticated SQL injection that sat in shipping code across multiple major versions. Both are “a CVE.” A number is not a risk assessment. Open the entries and look at the attack vector, the class, and how long the thing lived.

So, why are we “glad”?

Nobody is glad about a bug (thank you, Captain Obvious 😉). Here’s what we’re actually glad about, and the distinction is the entire point.

Glad the entry exists at all. “Zero CVEs” was never the flex people think it is, and we always knew where the hole was: a CVE only exists if somebody looked. Zero is equally consistent with “solid” and with “irrelevant,” and no amount of insisting fixes that. Somebody looked. This is what they found. One local privilege escalation, needing an attacker already inside the building, fixed in two days, six years ago. We will take that trade every single time, an honest entry beats an unfalsifiable boast.

Glad about the forty-eight hours. The response to a stranger’s email in 2020 was to fix it, verify it, and ship a version number that made the boundary unmistakable. Not to negotiate. Not to ask him to sit on it. Not to quietly slipstream it into a release three months later and hope nobody joined the dots.

Glad you’re reading this from us, ten weeks after the ID appeared, rather than from somebody’s competitive comparison page. If a vendor’s security posture only becomes visible when somebody else discovers it, that isn’t a security posture. It’s a press strategy.

Now go check us. Then go check everyone else.

The NVD is public, machine-readable, adversarially maintained, and profoundly uninterested in anybody’s marketing. Put this in your browser: https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=Syncplify

One result. The one above. Fixed in 2020.

Now change the keyword. Try whatever moves your files today. Try the one with the analyst logo on the slide deck. Or the one with an endless line of certifications. or the one you’re using right now in your company.

We’re not running those queries for you here, because a vendor listing a competitor’s CVEs looks precisely like what it is. Run them yourself. Read the entries, not the counts. It takes ten minutes and it’s the highest-value ten minutes in your whole vendor due-diligence process.

Found something? Contact us privately. We answer.

What’s changed?

• Fixed a UI regression just introduced in v8.0.7 yesterday, which essentially capped the number of users viewable in the Admin UI to 1,000 (this hot-fix restores the full uncapped user list)

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Fixed several issues with the new web UI that was introduced with v2.1.0, including uploading certificates, CORS, security headers, and more

• Fixed a backend glitch that would equate Any operation to No operation in the OpLog

• Updated the Go compiler and standard library to the most recent version, which comes with its own internal small bug fixes

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Fixed a glitch in the web UI which prevented the creation of new admin profiles erroneously reporting a “missing password hash” (it was a UI-only issue, not a password issue)

• Fixed a bug in the logging subsystem when outputting colored logs to a non standard tty

• Updated the Go compiler and standard library to the most recent version, which comes with its own internal small bug fixes

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• This is the 4th and last small step that completes our high-availability (HA) total redesign; functionally it’s identical to all other V8.0.x that preceded it, but the SuperAdmin UI now has gained the ability to automatically suggest correct bindings for each Node of each Virtual Site upon joining an HA cluster

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Fixed an edge-case bug in SyncJS’ RunAsync() function, which on POSIX systems could leave behind a zombie process if used to invoke a shell with a command line to execute a shell-script (very uncommon, but possible nonetheless)

• Added CtxVirtualSite() to the SyncJS scripting engine

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

SFTP-as-a-service asks for something different. It asks for your files, or the keys to get to them itself.

The trade nobody names out loud

Sign up for almost any managed SFTP or SFTP-as-a-service product and the pitch sounds the same: stop running your own server, stop patching, stop worrying about uptime. Let us handle it. Fair enough. Running SFTP infrastructure yourself is genuinely tedious (and often complicated) work, and offloading it is a real win.

But “let us handle it” almost always expands into “let us handle your files too.” Somewhere between signing up and your first transfer, one of two things happens:

• Your files land on the vendor’s cloud, sometimes briefly, sometimes permanently.

• Or, increasingly common, the vendor connects directly to your own S3, GCS, or Azure Blob storage, which means you hand over the credentials to do it: access keys, IAM roles, service accounts. The files never move, but the vendor now holds a set of keys that can reach in and take them whenever it wants.

Neither of those is optional in most SaaS SFTP products today. It’s their architecture, full stop. And the second pattern is easy to overlook, because nothing about it feels like “giving up your files.” It just feels like configuring a connection. The access is the same either way.

Why this became “normal”

It became normal for a boring, understandable reason: it’s the easiest way to build the product. If the vendor’s cloud is a waypoint your files pass through, or if the vendor has standing access to your bucket, the engineering is straightforward. Most of the category was built this way because most of the category needed to ship fast.

That doesn’t make it a requirement. It makes it a default that stuck around long enough to look like one.

The question worth asking

If the entire value of “as-a-service” is convenience, and the entire cost is access to your data, the real question isn’t “is this convenient.” Of course it is. The question is: does the convenience actually require the access?

Put another way: could a service manage the server, handle the protocol, take care of authentication and monitoring and all the operational weight, without ever needing to see, hold, or reach directly into your files?

We think the answer is yes. That’s the premise we’ve been building SFTP.cloud around: all of the “as-a-service” convenience, none of the “give us access to your data” part of the deal. And this diagram shows you how we did it.

Surprise! The compromise most of this category treats as inevitable turns out to be a choice, not a constraint.

What to watch for

If you’re currently comparing SFTP-as-a-service options, a compromise-free product should be identifiable by what it doesn’t ask you for:

• It shouldn’t need standing access into your storage, and it shouldn’t need your credentials to get it.

• It shouldn’t need your files to be cached or sit on its infrastructure at any point, ever.

• It shouldn’t care whether your storage is in the cloud or sitting in your own data center.

If a vendor can’t say yes to all three, you haven’t found the compromise-free version. You’ve found the default one.

We’re building SFTP.cloud to be the SFTP-SaaS that doesn’t ask for the trade. Early access is open to the first 100 people who want in: reserve your spot at SFTP.cloud. Not ready to commit yet? Subscribe to this blog and we’ll keep you posted.

What’s changed?

• Added a two-fold protection shield against Windows’ IRP leakage bug when remote storage accessed via SMB/CIFS becomes unavailable mid-session (this is a Windows bug, not ours, but we can now work around it)

• Added CtxUsername() to the SyncJS scripting engine

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

That’s not an accident. “Cloud SFTP” isn’t one thing. It’s three very different architectures wearing the same marketing label, and the differences between them matter a lot more than most vendors want you to notice.

If you’re evaluating a cloud SFTP solution, you need to know which one you’re actually looking at.

Flavor 1: “Cloud” just means “on a VM”

The oldest trick in the book. Take a normal SFTP server, install it on an EC2 instance or an Azure VM, call it “cloud SFTP.”

Nothing about the security model changes. You still patch it. You still manage the firewall. You still own every CVE that lands on it. The only thing that moved to the cloud is the hardware. This isn’t wrong, exactly, but it’s just not what most people mean when they ask for a managed cloud SFTP service.

Flavor 2: The vendor hosts it, and your files

This is what most people actually get when they sign up for a “cloud SFTP” or “SFTP-as-a-service” product today. The vendor runs the server. Convenient. But look closer at where your files actually live during and after a transfer, and the picture gets less comfortable:

• Your files are stored on the vendor’s infrastructure, at least transiently, often persistently.

• To connect your own storage, you typically have to grant the vendor access into it: an S3 bucket policy, a service account, an API key with read/write scope.

• If your storage isn’t cloud-native (an on-prem NAS, a SAN, a file server sitting in your own data center) you’re usually out of luck. Cloud-only storage backends are the norm, not on-prem.

• And on the storage side, inbound firewall rules are still the default, because something still needs to reach in and grab the files.

None of this makes a vendor incompetent. It’s just the architecture almost everyone builds, because it’s the easiest one to build. But “managed” quietly became a synonym for “someone else has access to your data,” and that trade got baked-in so early that nobody even questions it anymore.

Flavor 3: The one nobody’s really built yet (except…)

Here’s the question worth sitting with: why does a managed file transfer service need access to your files at all?

Not “why does it need to move them,” obviously it does, that’s the job. The question is why the vendor’s cloud needs to be a place your files sit in, or are even briefly accessible from. What if the cloud component only ever relayed a protocol, never held a byte of your data, and the connection into your storage only ever went outward, meaning nothing on the internet ever needs an open inbound port to reach it?

That’s not a rhetorical question. It’s the design question we’ve been working through at Syncplify for our upcoming sftp.cloud service, and we’ve already shared a piece of it: files that are never stored in our cloud, not during transfer, not at rest, not ever, paired with a lightweight connector that opens an outbound-only connection from wherever your storage actually lives.

We’re not ready to walk you through the full architecture yet. But we’ll say this much: if your current “cloud SFTP” vendor needs an inbound rule on your firewall, or needs permission to reach into your storage, that’s not an inherent requirement of the category. It’s just the version that got built first. And SFTP.cloud is designed to subvert that requirement.

What to actually ask

Next time someone pitches you a cloud SFTP or managed SFTP product, three questions cut through the marketing fast:

1. Does my data ever sit on your infrastructure, even temporarily?

2. What access do you need into my storage, and is it inbound or outbound-only?

3. Does this only work with cloud storage, or can it use on-prem systems too?

The honest answers will sort the three flavors above faster than any feature comparison page.

We’re building sftp.cloud to answer all three of those questions the way we think they should be answered. We just opened up early access to the first 100 people who want in: reserve your spot at sftp.cloud. Prefer to just keep an eye on things for now? Subscribe to this blog instead.

What’s changed?

• Fixed a bug in our Google Cloud Storage VFS implementation that prevented certain file-transfer clients from correctly unmarshalling directory names

• Added CtxVFSName() and EventCtx() to the SyncJS scripting engine

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Added support for Passkey sign-in to all UIs (SuperAdmin, Admin, and of course WebClient!) to include yet another strong authentication mechanism to the already rich set supported by Syncplify Server!

  

• Page-wide drop-zone to upload files and folders with a more modern user experience similar to Google Drive, OneDrive, etc… just drop the items you want to upload anywhere and they’ll be uploaded into the current directory displayed in your WebClient! UI at that time

  

• Fixed a compatibility issue in our OIDC implementation that prevented login completion when connected to Microsoft Entra ID (note: all other OIDC providers were already working well, this issue was exclusively related to the way the optional “alg” claim is handled, which Entra ID does differently from any other OpenID Connect IdP)

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

These are not just UX gimmicks, they genuinely help you keep your account safe, especially the passkeys, which are our most highly recommended login method going forward.

So, how do you enable those features?

First of all, perform a normal/legacy login with your current credentials. Once you’re logged in, click the Account settings menu item in the left sidebar.

Once you are in your account settings page, click on the Sign-in methods button in the top-right corner of the page:

You will be forwarded to this page:

From there you can:

• change your password (always make sure you have a strong password regardless of what sign-in method you actually use)

• add/rename/remove passkeys (arguably the safest sign-in method)

• connect/disconnect your social logins (security depends on how safely you have them locked down, but they’re usually pretty safe)

We strongly encourage each and every one of our customers to adopt passkeys whenever possible, or at least connect one of their social accounts that are already protected by their providers’ authenticator apps, and use that account to sign-in from there on.

Thank you all for helping us keep your customer accounts safe.

What’s changed?

• Improved accessibility (WCAG 2.2 AA) and usability (UX) of the WebClient! UI with a small set of targeted optimizations

• Added an all-new CtxRelTargetPath() to our scripting engine, specifically designed to retrieve the destination (target) relative-path inside of the AfterFileRename event-handler

• Backups taken from nodes that used to be part of an HA cluster and then they left and went back to being stand-alone single servers now no longer contain legacy HA node bindings

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

It’s available exclusively with the Ultimate license tier, and if you’re running one, it’s already there waiting for you.

What it is

Sixteen built-in operational reports, accessible directly from the Admin UI. Print them, download them, export them to JSON/CSV for further analysis, or just read them on screen. Every report is generated on demand from live data, so what you see reflects the actual state of your environment at the moment you run it.

The reports span several domains, including (but not limited to) operations, compliance, and security. And more will be added in future updates.

Why it matters more than it looks

Here’s the thing about enterprise file transfer environments: they accumulate. Users get created and forgotten. Permissions get granted and never revisited. Accounts that were set up for a partner integration three years ago are still sitting there, idle, with elevated access to production directories.

Nobody meant for that to happen. It just did, incrementally, across hundreds of small decisions that were each perfectly reasonable at the time.

Compliance audits and security reviews surface these problems, but only after the fact, and usually in the most stressful possible context. Enterprise Reporting gives you the visibility to catch them on your own schedule, before anyone asks.

Just two of the many possible examples that illustrate this well.

Inactive users shows every account that hasn’t logged in for 90 or more days, with a last-login timestamp and a total login count. That login count matters: an account with hundreds of historical logins that has gone silent for three months is a different conversation than a test account someone created and never used. Both are worth reviewing. Now you can see both at a glance, any time you want.

Elevated access shows which users have been granted permissions beyond the default, on which mount points, and against which Virtual File Systems. Delete directory. Delete files. Create symlinks. Each permission is listed individually per user, per path. If you’ve never run a report like this in your environment, the result may surprise you.

Not just for auditors

It’s tempting to think of compliance reporting as something you pull out when someone asks for it. A checkbox exercise.

The more useful mental model is operational hygiene. Inactive accounts expand your attack surface. Excessive permissions increase the blast radius of any compromised credential. Neither of these is a theoretical risk in environments moving sensitive business data over SFTP. Both are problems you can actually see and act on, now, without waiting for an external audit to tell you they exist.

That’s what this module is for.

All 16 reports, with more to come

The current release includes 16 built-in reports, here’s a list grouped by category.

Access & Identity

• VFS by user

• Users by VFS

• User inventory

• Authentication & MFS

• Inactive users

• Failed sign-ins

• Elevated access

Security & Compliance

• Blocklist

• Certificates & keys

• Security posture

• Shared objects

Storage

• Storage inventory

Activity

• User statistics

• Traffic & sessions

• Unused app-passwords

Automation

• Automation inventory

Future updates will add to that list. If there’s a specific report type that would be useful in your environment, reach out. We listen.