Security model

This page states what the design actually guarantees, and what it does not. It is written for somebody who has to justify the service to a security team.

The one structural property

Syncplify never holds your files.

They live on storage you own, reached by a Storage Connector you installed on your own hardware. No component we run has a path to them. There is no bucket of yours on our infrastructure, so there is none to leak, subpoena, or misconfigure.

Everything else on this page follows from that.

Where each thing lives

Thing	Held by	Reachable by Syncplify
Your files	Your storage	no
Your file permissions	Your Connector	no
Your at rest encryption keys	Your Connector	no
Your Connector's admin accounts	Your Connector	no
Your transfer users' passwords	Your site, hashed with bcrypt	only under an active support grant, and never in readable form
Your transfer users' SSH public keys	Your site	as above
Your transfer users' second factors	Your site, encrypted at rest	as above
Your Portal account credentials	The Portal, hashed	never in readable form
Your account, plan and invoices	The Portal	yes
Your audit trail	The Portal	yes

Connection direction

Every connection goes from lower trust toward higher trust, and never the other way:

Users  ---->  Your site  ---->  The Portal
                  ^
                  |
          Your Connector

Your Connector dials out. Your site dials out. Nothing ever dials in.

Consequences: no inbound firewall rule for the Connector, no public address for it, no DNS name for it, and no listening port on it that the internet can reach.

Why controlling your site is not controlling your files

Authentication and authorization are split across two machines.

Your site proves who somebody is. It checks the password, the key, the second factor.

Your Connector decides what they may do. It holds the grants and enforces them on every operation.

The Connector will not act on an instruction unless it carries an identity record signed by the Portal, verified against a key that is compiled into the Connector binary and delivered to it at enrollment without your site's involvement.

So a site that has been fully taken over can refuse service, and cannot mint a user, forge a grant, or read a file.

What each session must carry

Every session your site opens on your Connector presents:

1. A Portal signed identity record for the user, verified against the Connector's built in anchor.
2. A site signed session voucher, minted for that one sign in, checked for freshness and checked for reuse.
3. For strong authentication, the client's own proof, relayed and verified against the public key in the identity record.

The Connector checks that all of them agree about the user, and clamps the session's lifetime to a ceiling that came from the Portal, not from your site.

Enforcement

Every file operation is checked at the moment it happens, on the Connector, before it reaches the disk.

A valid identity with no local grant is refused. There is no default access and no default home directory.

A refusal returns a uniform error. The real reason is recorded in the Connector's log and never sent to the user.

The signed record

Every operation, allowed and denied, is written to a signed record on the Connector that cannot be turned off.

At intervals the Connector signs a commitment describing what that record contained, and the Portal records it. Once recorded, the log up to that point cannot be rewritten without the difference being provable, including by whoever owns the machine.

The verifier is public, open source, dependency free and read only, and the format is specified in enough detail to be reimplemented. See Tamper evidence.

Supply chain

Every Connector update package is verified against a release key built into the Connector binary before anything is applied.

That key is held offline by Syncplify. Neither the Portal nor your site holds it, so neither can distribute an update a Connector would accept, however compromised they were.

Container images are cosign signed, and the signed digest is recorded in the release channel index.

Support access

By default, Syncplify support sees aggregate metadata about your account and nothing else.

A support grant is your explicit, time limited consent, created only by somebody signed in with the admin role. It is enforced in the API, not by hiding interface elements.

Under a grant, support holds read capabilities only, plus a narrow credential recovery path that can remove a lost factor and send a reset link to the account's own address. It can never set a credential and never sees one.

Every action under a grant is written to your audit trail with the grant's id.

Nothing under a grant reaches your Connector, your storage, or your files.

What this design does not protect against

Stated plainly, because a security model that only lists its strengths is not one.

Somebody with access to your Connector machine. They hold your encryption keys and your grants. Treat that machine as you would a file server: it is one.

A compromised Portal account with the admin role. They can create users, mint enrollment codes and grant support access. Which is why two step sign in is mandatory, passkeys are offered, and every action is in the audit trail.

A password on SFTP, FTPS or FTPES. Those protocols cannot ask for a second factor. A password there is a single factor. Two remedies, in order of strength: an SSH key with the password removed (see Use an SSH key), and a protocol scoped, revocable app password per program in place of the one account password everywhere. A site can also connect an identity provider, in which case the browser sign in is your organization's and its MFA rules apply there; the transfer protocols still take an app password or a key, because a browser sign in cannot be typed into a desktop client.

A user doing what they are permitted to do. Permissions are a control on what people may do, not on what they should.

A share link you sent to the wrong person. Set expiries, set access limits, and delete shares when they have served their purpose.

Your storage provider. If your files are in somebody else's bucket, that party can reach them unless you turned on at rest encryption. See Encryption at rest.

Loss of your encryption passphrase. Nobody can recover it. That is the property you wanted, and it cuts both ways.

Compliance questions

The facts a security review usually asks for:

• Files at rest are held by you, in storage you chose, under your own retention and residency rules.
• At rest encryption is available and the key never leaves your premises.
• Data in transit is TLS 1.2 or better, with post quantum key agreement offered on every plan.
• Access is logged on both sides, and the customer side log is tamper evident and independently verifiable.
• Vendor access is consent gated, time limited, read only, and audited.
• Availability is measured monthly, published including bad months, and credited automatically.