What’s changed?

• Fixed a bug that caused uncompressed log files not to be deleted upon their archival (gzip); this bug only affected the Windows version of our software

• Fixed a UI glitch that prevented the export of the host’s SSH public keys

• Added the ability to customize the tab title and “favicon” for WebClient!

• Bumped up the usual set of minor dependencies

As always, 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?

• Some password managers (like Keeper for example) append extra (unrequested) fields during the creation of a new passkey; up until and including v8.6.0 we treated any extra field as a threat, which caused Syncplify Server! to simply reject the request outright. As of v8.6.1 the verification process has become slightly more lenient, and some (not all) unrequested fields are now simply ignored, which allows such password managers to enroll passkeys even though their request is technically incorrect, but only after the request has gone through thorough server-side sanitization

• Bumped up a few minor dependencies

As always, 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?

Every log line that has a severity level of INFO or above (that includes WARNINGS and ERRORS of course) now gains a numerical eventId.

All event IDs are documented in the manual.

This might seem like a small change, until you realize that in 2026 logs are no longer read by humans. They are analyzed by automated processes, fed to SIEM systems, and ever more frequently processed by AI agents.

Of course all the human-readable comments in our logs are still there. This was an additive feature, not a replacement. But having clear and consistent event IDs associated to each meaningful log line makes a world of difference when it comes to automating the processing of those logs (for example by a SOC).

As always, you can download the most recent release from our website, or if you’re running any version newer than v8.3 you can simply update your software live, with the push of a button in its SuperAdmin UI.

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

What’s changed?

• Fixed a minor bug that caused the Users collection not to be imported from an old V6 backup if any of the user accounts had no credentials at all; if you had no user accounts in your new V8 after importing your old V6 backup, this release fixes that issue

As always, 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?

• The recently introduced automatic self-update feature suffered from a bug that made it unable to use local on-prem DNS resolvers to check the maintenance plan validity (causing false positives that customers found confusing); This release fixes such odd behavior.

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 an integer normalizer to the PKCS#1 importer (only to make it easier to import backups from older versions with configurations older than 6 years ago)

• Bumped up a few minor dependencies

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

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

They have no idea who you are, which is the unintuitive part, and it’s also why the whole subject tends to get quickly dismissed as a “a problem for next year… or the one after that”.

It’s not like a Mission: Impossible movie, where someone is sitting outside your building with a laptop inside a suspiciously windowless white van. This is a slow game, patient… and cheap: capture encrypted traffic off a backbone, store it, and wait. Storage is the only cost, and storage has never been cheaper.

This strategy has a name: harvest now, decrypt later (or HNDL for short). It’s an attack against the key-exchange, which occurs at the start of a session where two machines agree on a secret to protect a channel anyone can read. Everything after that depends on it. Break the key exchange and you have the session. All of it. Whenever you get around to it.

Classical key-exchange is breakable by a sufficiently large quantum computer. We’ve known how to for years. The only question still open is the date, and that date is approaching faster than ever before.

The session you are having today is the one you cannot fix

A session captured in 2026 and decrypted in 2034 is a 2026 breach with a 2034 discovery date. No amount of later diligence can go back in time to fix it. The upgrade has to happen before the traffic exists, which means now.

If you transfer payroll files, patient records, insurance claims, financial statements, engineering drawings, legal discovery… very little of that becomes harmless in a decade. Some of it never does.

What we actually negotiate

Every protocol we terminate negotiates a hybrid post-quantum key exchange:

• SFTP negotiates mlkem768x25519-sha256, which is ML-KEM-768 combined with X25519

• FTPS, FTPES and HTTPS negotiate X25519MLKEM768, the TLS 1.3 equivalent

And hybrid is the keyword here. Both halves run, and the session key is derived from both. An attacker has to break the classical exchange and the ML-KEM to decrypt the session.

And behind the protocol endpoints…

The four protocols are the part your clients connect to. But there is a second set of connections behind them that most vendors never talk about: the platform’s own control plane, and its relative inter-component data plane.

For example, a session on SFTP.cloud involves three components: the Protocol Head that terminates your connection, the control plane that authorizes it, and the Storage Connector running inside your own network. Every link between those components is mutually authenticated TLS (or mTLS for short) and every one of those links also negotiates a hybrid post-quantum key exchange.

Where everybody else stands

We checked the published documentation of nine other vendors on September 21, 2026. Their own official release notes, cipher lists and security pages. Here’s what we found.

AWS Transfer Family has support for hybrid ML-KEM key exchange since May 2025, selected through a security policy, but they only support it for SFTP. Their own security policy reference shows the TLS cipher section is unchanged, so AWS Transfer Family’s FTPS remains only classical.

Files.com has a standing documentation page on post-quantum cryptography, where they say they will ship across HTTPS, FTPS and SFTP when the ecosystem is ready. They also say that there is no target date, and their published cipher list confirms nothing has shipped.

Five other vendors are documenting cryptographic work and leaving post-quantum out. GoAnywhere added four classical Diffie-Hellman key exchange algorithms to its FIPS mode in April 2026. Cleo added three more in the Harmony 5.8.1 line, patched as recently as 10 September 2026. CrushFTP publishes a complete enumerated key exchange list with no hybrid entry, in a changelog that tracks cryptography closely enough to record removing DSA. Serv-U's July 2026 release notes document an OpenSSL update to version 3.0.21, which is several series below the one that introduced ML-KEM. MOVEit Transfer 2026's release notes give OpenSSL 3 and FIPS mode as the cryptography headline and doesn’t mention post-quantum anywhere.

Finally, three other vendors publish too little to say anything about them. Kiteworks, Couchdrop and sftpcloud.io do not publish their cipher inventories, or at least we weren’t able to find them. Absence of a mention is not evidence of absence though. All we can say about these is that we simply don’t know what they support.

Before you compare datasheets…

If you go and read those pages yourself you will run into statements like “FIPS 140-3 everywhere”, often as the headline cryptographic claim for a 2026 release.

FIPS 140-3 is a validation that a cryptographic module is correctly built and correctly implements approved algorithms. It says literally nothing about quantum resistance, because the approved algorithms it validates are only the classical ones.

So the two properties are independent. A product can be FIPS 140-3 validated and still not at all quantum-secure.

The client’s role in all this

The client has to cooperate. A hybrid post-quantum key exchange requires both ends. Connect with an OpenSSH 8 client and you will get a classical exchange, because the alternative would be to refuse the connection.

To ensure older client software is supported, SFTP.cloud does also offer classical key-exchange algorithms, but hybrid post-quantum are always preferred when the client-side also supports them. And if your SFTP.cloud site runs on a Dedicated Tier instance, you can configure strict post-quantum resistance, refusing all classical-only algorithms outright (if you so wish).

Check it yourself, it only takes a minute

You do not have to take any of this from us. Against any SFTP endpoint, ours or your current one run this:

ssh -vvv -p 22 user@endpoint 2>&1 | grep -i “kex: algorithm”

If the answer contains mlkem or sntrup, that session was post-quantum. If it comes back with curve25519-sha256 or a diffie-hellman-group variant, it was not.

And for your FTPS, FTPES, or HTTPS endpoints, ask the TLS handshake which group it settled on. You just need OpenSSL 3.5 or later to run this:

openssl s_client -connect host:port -groups X25519MLKEM768 </dev/null 2>&1 | grep -i “group\|Negotiated”

Run it against us. Then run it against the MFT solution you use today.

Sources

• OpenSSH post-quantum cryptography

• Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3

• AWS Transfer Family, post-quantum security policies and security policy algorithm reference

• Files.com, post-quantum cryptography and published cipher list

• GoAnywhere MFT release notes

• Cleo Harmony 5.8.1 release notes

• CrushFTP SFTP algorithm list and build changelog

• Serv-U 2026.3 release notes

• MOVEit Transfer 2026, what’s new

SFTP.cloud terminates SFTP, FTPS, FTPES and HTTPS in front of storage you already own, without holding your storage credentials and without writing your files to our disks. How it works covers the architecture, and Security covers the threat model.

• A bug in our logging library, specifically affecting the syslog target, has been identified and fixed; now a stuck syslog server can no longer cause resource channel lock-up in your Syncplify software.

As always, you can download the most recent release from our website, or if you’re running Server! v8.4.0+ or R2FS! v3.0.0+ you may (more easily) self-install this update with the push of a single button in the web UI.

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

What’s changed?

• If you’re running any version of Syncplify Server! between v8.1.2 and v8.4.0 your service might CRASH (and auto-restart) when the following two events happen to occur symultaneously:

  • a log file is rotated

  • a client disconnects at the exact same time

  Version 8.5.0 fixed that specific race condition. We apologize to anyone affected by this bug, and we urge everyone to update to v8.5.0 so that this doesn’t happen anymore.

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

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

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

But v8.4.0 carries a lot more than that. It carries a robust set of security improvements which would not have been possible without the help of one of our customers, but since we’re a security company we’re not going to name them here. We’ll just say this: You know who you are, and we cannot thank You enough!

They provided us, free of charge, with the best security assessment and pen-testing our software has ever been put through. Ever.

And that act of kindness and genuine support lead v8.4.0 to also include the following changes and improvements:

• More sensible default configurations for newly deployed instances (do not apply to updates/upgrades for obvious reasons) including but not limited to:

  • STARTTLS auth now defaults to “Required” on FTP bindings

  • Pinned-key mTLS is now on by default for all R2FS! bindings

  • SyngoDB management service now binds to 127.0.0.1

  • More sensible SANs in default self-signed certificates

  • More sensible HTTP security headers by default

  • Worker process auto-restart is now enabled by default

• Tightened ACL on database and log files

• Tightened systemd unit file configuration for all services (Linux only)

• Fixed “Timing Oracle” exposure that allowed an attacker to tell apart existing from non-existing usernames by simply measuring the server’s response time

• Legacy ssh-rsa weak host key algorithm was an automatic “re-entrant” if the SSH/SFTP service had any RSA host key in its configuration (now disabled really means disabled instead)

• Hardened build pipeline now prevents builds from a “dirty” repo (a repo that has uncommitted changes) and forces PIE executable builds on Linux

The report we received also included a couple of false positives, which we verified (not assumed) to be false positives, and as such were not addressed.

It’s important to understand that all the security improvements to the executables and environment are automatic for everyone, new install and updates/upgrades alike. But all the improvements to the default configurations are only applied to new installs, so if you’re updating/upgrading to v8.4.0 from an older version you’ll still have to review your own configuration to ensure it’s the tightest possible (compatibly with your specific needs).

We hope this addendum to the previous v8.4.0 release note effectively conveys why we consider v8.4.0 such an important update for everyone running our software.

As usual, thank you all for your attention, and for being part of our journey.

What’s changed?

Learning from the lessons we learned developing SFTP.cloud, we added what’s likely the most requested feature ever, automatic self-service updates, to both Syncplify Server! and R2FS!

The SuperAdmin UI gained a new page, called Updates:

And you can now elect to be notified only or create your own auto-update policy:

Updates are graceful: the node being updated is put into “drain mode”, patiently awaits until there are no more ongoing client connections, then self-updates and restarts, all automatically.

Updates are also safe in HA cluster deployments: when running as part of an HA cluster, nodes take turns and update themselves one by one, verifying the success of the update and the node’s health before moving on to the next node.

NOTE: you will still have to download and install this one update manually, then once you’re running Syncplify Server! v8.4.0+ or R2FS! v3.0.0+ all subsequent updates can be automated.

Also, please, be aware that the automatic self-update feature does check the validity of your maintenance plan. Only active and current maintenance plan holders are eligible to receive updates and upgrades. Thank you for keeping your maintenance plan active and current.

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

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

1. It’s literally the platform’s domain name, so the dot is pronounced by default.

2. Just like Microsoft’s .NET platform (pronounced “dot net”) the dot in SFTP.cloud is also an integral part of its name.

3. We don’t want to be confused with “sftpcloud” which is a different service that has nothing to do with Syncplify or SFTP.cloud.

And here’s the official wordmark, to leave no ambiguity as to how it’s written:

As always, thank you all!

Now, after nearly 13 years of honorable service, we’re retiring Protector in favor of a completely new design. The change is so radical that we felt it appropriate to use a different name for it. We now call it Shield.

But… why?

Shield was developed as part of the SFTP.cloud project, and within 2 hours of its release it had already proven itself on-field, against a distributed botnet attack.

Of course we were pleased with the result, but that got us thinking: how would have Protector fared against the same attack? Luckily we had a few dozen megabytes of very detailed logs that allowed us to re-simulate the entire attack shape and run it against both Protector and Shield to measure the results.

First and foremost, it is important to say that both Protector and Shield handled it with a 100% success rate. But then, why is Shield such a big deal? If both technolgies prevented 100% of these attacks, why is Shield so far superior?

It all comes down to four aspects:

1. Resource usage: while the attack was underway, Protector used up ~8% of the host machine’s CPU to prevent it, Shield did the same while using only ~0.1% (that’s 80 times fewer CPU cycles)

2. Long-term memory: Protector didn’t have any, so every attack was a new event from its perspective, which means that “slow and patient” attacks are dealt with but never prevented. Shield has memory. It remembers the behavior of each attacker for a certain (configurable) amount of time, and is capable of preventing re-attacks from known sources far more effectively using such knowledge.

3. Shield is fully deterministic: Protector was partly deterministic and partly probabilistic, leading it to raise the occasional false positive here and there. Shield is fully deterministic, leading to far fewer (in the vast majority of cases absolutely zero) false positives.

4. Flexibility: Shield can be fine-tuned much more granularly than Protector, which increases its flexibility by a huge margin.

So, what does it look like?

Well, first and foremost its UI is far more informative than the old Protector. Shield gives you a lot more information about each ban and what caused it.

It also provides a real-time view of its current status, including a list of IP addresses that are currently under review (have strikes) and why.

And, like we said, it’s highly configurable/tunable, but it comes with built-in sensible defaults, so most operators won’t ever have to “mess” with it.

How can you get it?

Simply update or upgrade to Syncplify Server! v8.3.0 (or newer) and Shield is built-in, your old Protector is gone, and your old banned IP list and safe-list are automatically converted to the new format.

What’s changed?

• Dropped the old Protector, and adopted the far superior Shield, developed over the past 18 months as part of the SFTP.cloud project, which in just hours after launching the new platform has already proven itself ~80 times more efficient (and more accurate)
  > a dedicated blog post, with a full explanation, will follow <

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

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

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

What happened exactly?

At 16:48Z, 56 distinct addresses arrive inside one minute. By 17:01Z the rate peaks at 211 attempts a minute. Note the shape of it: through the whole opening phase the count of attempts and the count of distinct source addresses are nearly identical, one attempt per host per minute. This is clearly a botnet deliberately spreading its guesses thin so that no single address trips a per source counter quickly.

It goes on for thirteen minutes. Then arithmetic catches up: the adaptive strike window at that point in time is narrower than 20 minutes, so around 17:02Z hosts begin crossing five accumulated failures and the bans start. The ban rate peaks at 61 in the minute of 17:09Z. From there the two curves cross. Traffic stops reaching the authenticator and starts bouncing off the accept gate instead.

The crossover at 17:13Z is the shield taking hold. Everything to the right of it is the attack still arriving and being dropped at TCP accept, before a key-exchange event even has the chance to occur.

What were they shopping for?

268 distinct usernames were tried. The head of the distribution is the expected system account sweep (we guessed usernames like root and admin, and log analysis proved us right): together they represent roughly 32% of all attempts.

The interesting part is the second cluster. wallet, crypto, solana, blockchain, exchange, metaverse, plus xmr, monero, eth and binance further down. That is 951 attempts, or about 19% of the total, hunting for crypto custody hosts rather than generic shells.

A third cluster names hosting control panels: whmc, ubersmith, cerberus, panel. And the long tail is a first name dictionary, five attempts each, which is what the single most persistent host in the log was patiently grinding through.

SFTP.cloud’s automatic shield held end-to-end

Nothing authenticated. Across 4,925 attempts from 937 addresses there is not a single successful attacker login on any protocol. The only successful sessions in the entire window are seven WebClient logins by a legitimate user account from a single address.

The cost model held. The accept gate refuses a banned source before the SSH key exchange, so 6,321 of the connections in our logs cost essentially nothing. That’s why the protocol-head process never moved above 0.1% CPU usage while 200 hosts a minute hammered it.

Persistence held. Bans survived in the database and the RAM index rebuilt cleanly. 120 bans expired and were lifted on schedule during the window, with no drift.

A good day’s work

Throughout the entire attack, our SOC staff sat there, watching it all unfold, keeping an eye on resource usage, making sure legitimate users were still signing-in without hiccups.

All they had to do was watch. SFTP.cloud protected itself, silently and efficiently, exactly as it was designed to do.

And the very first question we received? “Show me its WebClient”. Alright, that’s fair.

So here it is. Showing you both views of the same directory, to show off the optional thumbnails (in gallery view, cached on the browser to avoid wasting bandwidth) .

Now, the most observant among you will surely be drawn more to the bottom-right side of those screenshots, rather than the file-views.

What is the Transfers panel telling us? It’s actually telling us a very interesting story:

• New file uploaded from the browser need the browser to stay open to come to completion (just like Google Drive, OneDrive, and basically every other tool of this kind when accessed via web interface)

• But file copies/moves between existing locations are carried out on the server: they can be cross-VFS and even cross-Connector, and they survive if the browser tab/window is closed after initiating them

Moving on, of course no product of this kind would be complete without the (optional) ability to create “shares”, to share individual files or entire folders with external third parties in a controlled manner. So here we go:

The process is guided, and the security and convenience features cover many aspects, like, for example:

• Granular access controls

• Password-protected access (well, duh!)

• Maximum number of times the “share” can be accessed before it self-expires

• IP-based allow-list (individual IP addresses and network CIDRs supported)

• Anonymous sharer identity

• Automatic email notification to a list of recipients

And here’s how one such recipient sees the object shared with them:

And the beauty behind all this? The physical storage behind all that was never held by SFTP.cloud in the first place!

• Connect your own storage: SFTP.cloud will never hold a copy of your files

• Encrypt it with your own keys: SFTP.cloud will never have them

• Safely and securely share whatever you want with whomever you want: SFTP.cloud is just your quantum-secure protocol-head in the cloud

More to come, soon.

And here’s the interesting part: neither of them gets away scot free.

In fact, those who can plan for update windows get annoyed with “rolling release” vendors, because they add too many items to their already busy docket.

And the second type… well… they’re the reason why we still find customers on V4 when the current release is V8. It works just fine, and they can’t afford the downtime to upgrade. To be fair this type often splits into two sub-types: those who do not update, and those who deploy HA clusters behind load-balancers to be able to upgrade their nodes one by one without interrupting the service as a whole.

Up until now we’ve never felt this could be, at least in part, our responsibility. But, oh boy, were we wrong! Having spent the past year and a half developing all the SFTP.cloud components threw us head-first directly into those operators’ shoes. We quickly realized we had to come up with a better approach.

So, how do SFTP.cloud components update with zero downtime?

As it often happens there are two sides to this story:

• The Protocol Heads, the machines serving SFTP, FTP(E/S) and HTTPS, accepting incoming client connections, are the ones we operate. On top of load-balancing and clustering, each one of these nodes is also designed to hand over the listening socket to the incoming (upgraded) process, so connections survive the changeover without ever being rejected by a closed port.

• The Storage Connector, sitting in your data center, does something different. The new version starts up alongside the old one, dials the Head over its own reverse tunnel, and gradually takes over new work. The old binary keeps the transfers it already had, carries every one of them through to completion, and exits only once it has gone idle. At no point in the chain is there a gap where a transfer is dropped or interrupted.

The Head side updates/upgrades are orchestrated by an automation process that staggers the updates and delivers them in tiers, verifying each tier before moving on to the next. Any error during the process is an automatic zero-downtime rollback.

The Storage Connector side is capable of fully automatic self-updates, but it can be configured to wait until an operator decides to do the rollout. And still there’s nothing to keep an eye on, download, type in the command line… it’s just one button in the Connector’s Admin UI. One click. A few seconds of wait time. Walk away with a smile on your face.

Syncplify Server! and R2FS! come next

We decided to take it one step further. Now that we’ve developed the technology, we believe the same approach would also benefit our Syncplify Server! and R2FS! customers. After all, they are the ones who operate our self-hosted software, so it seems fitting to offer them the same convenience.

We have, therefore, begun a two-pronged effort to integrate the same zero-downtime update/upgrade features into those pieces of software as well.

Because it’s all about security

We don’t release updates for the fun of it, or to annoy our customers with yet another upgrade task to plan around. We release them because the threat landscape keeps shifting. And now, with the advent of AI, that shift is faster than ever before.

If you’re still running an old V4 or V5, you’re simply not safe. It works, yes, it works really well. But it’s vulnerable to attacks that didn’t even exist when that version was released. Keeping your software up to date is the one shield that protects you more than anything else.

Now, with SFTP.cloud that’s also easier than ever. And soon it will be, too, for Syncplify Server! and R2FS!

What’s changed?

• Fixed a cosmetic bug in the Admin UI that “forgot” that all usernames must be lowercased to ensure POSIX compliance effectively

• Upgraded SyngoDB to v6.12.0, which fixes a bug with the finder’s planner when the AND clause is used in conjunction with two distinct compound indices

• Upgraded the Go compiler to 1.27 (which comes with its own set of bug-fixes in the language’s standard library)

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

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

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

Fair question. And if we have to answer it with the same fairness, it means separating two things the industry insists on (confusingly) calling by the same name.

A CONNECT tunnel (or its SOCKS5 equivalent) relays TCP bytes it cannot read. Your TLS handshake happens with the real server, end-to-end. All this “proxy” learns is a destination, a port, and some byte counts.

An intercepting proxy, sold to you as SSL/TLS inspection (aka “break and inspect”, ring any bells?) terminates your session, decrypts it, and opens a second one onward using a certificate your endpoints were configured (read: forced) to trust. That is a man-in-the-middle device with a support contract, and one compromise exposes every session that goes through it.

The distinction is not academic for us. The Syncplify Server!-R2FS! pair, and all components of SFTP.cloud SaaS guarantee hybrid post-quantum cipher-suites between all of their control plane components, and that guarantee can only be true when it can be established and verified end-to-end.

What these SSL/TLS intercepting proxies leave you with is a PQC connection to the middle-man, and an Agatha Christie-sized mystery beyond it.

We use mutual TLS (aka mTLS) with pinned certificates, which cannot survive interception by design, so the handshake fails at connect time. There is no silent downgrade path, and we will not ship a “skip verification” flag, because there is no moment when using one would be safe.

So, the only fair answer is: proxy traversal via CONNECT and SOCKS5 is on our roadmap, we’ll do it. Support for TLS-intercepting proxies is and always will be explicitly unsupported.

Proxying was never the problem. Interception is. Yes, even the type that a trillion dollars worth of marketing convinced you that “it’s for your own safety”: that’s how two out of three of the US’ major Telcos were hacked just last year. Not on our watch.

And we published a 9-minute video that shows the platform in action, end to end, for the first time.

The video covers some of the most common quick-start topics, like:

• How to sign up

• How to create your first site

• How to create your first transfer-user

• How to connect your own storage (Linux and Windows)

• How to transfer some files (via its WebClient UI)

Nothing fancy. Just the basics. But it can point you the right direction, because the way our platform works is unlike any other cloud-based SFTP/MFT you may be familiar with.

With SFTP.cloud, in fact:

• Your files never touch our servers. Not cached nor staged anywhere on our side.

• We never hold your storage credentials. There is nothing in our infrastructure that could be stolen and used against your data.

• Nothing new opens in your firewall. Your Storage Connector dials out to us. Nothing dials in.

• Post-quantum cipher suites on SFTP, FTPS, FTPES and HTTPS. Yes, all four of them from day one.

• Two signed audit trails per session, one written on your side with a key we never have. Neither of us can quietly rewrite what happened.

• Cross-VFS and even Cross-Connector managed transfers. Move files from your New York office to your Tokio subsidiary on a scheduled job, or a simple drag and drop.

• At-rest encryption with your own keys. Keys you never have to give us, not even temporarily.

And all that needs to be shown, not just talked about. Now we have.

And for those of you who may be interested in this service, there’s still a little bit of time to sign up for the second wave of early adopters (who, just like the first wave, will also receive a discount when the platform launches officially, after its early-access period runs out).

Thank you all!