Security
Every read and every publish is a request Syncture authorises before a byte moves. No workstation holds a storage credential, and there is no bucket to address. A workspace is created either with encryption on or off, and off is the default. This page says what each kind stores, what we hold either way, and what we do not have.
The five answers a questionnaire asks for
How access is decided
By the service, on every request. The caller's workspace membership, shares and groups are resolved against the thing being reached before anything is returned. Withdraw somebody's access and it is gone on their next request.
What your firm controls
Who is in the workspace, what each share allows, per folder and per model, and whether the workspace is created with encryption on. A viewer's publish is refused by Syncture itself, so there is no button to unhide and no client to modify.
Where it sits
Files sit in Cloudflare R2, in the region the account was created in, and do not move. European accounts hold them under Cloudflare's EU jurisdiction, which keeps them inside the European Union. Every name, path, share and invoice is in one database under the same EU jurisdiction, for every account.
Whether the models are encrypted
Chosen once, when the workspace is made, and off unless you turn it on. With encryption on, every published file is encrypted by the add-in on your own Windows machines under a key you hold. Without it, the file is stored as published.
What we can see
Workspace, folder and model names, every file's relative path and exact byte length, publish times, authors, notes, the share graph and lock state. That list is the same in both kinds of workspace. No process in the service opens a Revit file for any purpose of ours, training included. That is a term of the contract.
The two kinds of workspace
Encryption is off unless you turn it on when a workspace is created. The choice cannot be changed afterwards.
Without encryption
The default. Models are stored in a form we can read, which is what lets the service serve, deduplicate and version them. The section below sets out what limits that reading.
With encryption on
In a workspace created with encryption on, the bytes of every file you publish are encrypted on your own Windows machines. So is every element-ownership document. The Syncture add-in does it, under one 256-bit key generated on your side and never transmitted to us. We store what an encrypted workspace publishes and cannot decrypt it.
What we hold either way
Workspace, folder and model names. Every file's relative path and exact byte length. The number and stored size of each encrypted piece, publish times, authors, notes, the share graph and lock state. A version's file list, when it is too large for a database row, is written to the object store as plain JSON.
If the key is lost
The versions published into that encrypted workspace cannot be recovered, by you or by us. No copy of the key exists in our systems from which one could be derived. A workspace's key cannot be changed, and models cannot be moved between workspaces. So the key is deployed across the estate before anybody publishes.
One key can open every workspace your practice owns, and it reaches your machines through Group Policy, Intune, an RMM or a vault you already run.
The default, and its limit
A workspace created without encryption is stored in a form we can read, which is what lets the service serve, deduplicate and version it. Somebody with production access could open one. So the question is what stops it.
Three things. We process customer files only to store and serve them, on your instructions and for no purpose of our own. Production access exists to deploy the service, respond to an incident, and answer a support request you raised. The Terms, the privacy policy and Austrian law make those enforceable.
Two consequences belong in a questionnaire rather than in a discovery six months later. Under valid legal process we could produce a model in readable form. A model published into a workspace created with encryption on is not one of those. You would be told about a request either way, unless we were forbidden to tell you.
What holds that up
Every request is authorised
Nothing on a workstation decides what that workstation may do. A request somebody writes by hand is refused on exactly the same grounds as one the add-in makes.
There is no bucket to address
No machine holds a storage credential and no client reaches object storage directly. A stolen laptop carries no credential that reaches the store. Full-disk encryption is the control for what is on its own disk.
Credentials last one hour
A machine holds an access token good for one hour, exchanged from a 90-day device secret that is replaced every time it is used. Using a copy is detected on the real machine's next exchange, because the secret it presents is no longer current.
There is no password
Signing in is Microsoft, Google, or a code we email, so there is no password of yours for us to store or to leak. Sign-in codes are held as peppered hashes for a few minutes.
No share link exists
Every grant names a person or a verified domain. There is no URL that grants access, so nothing can leave by being forwarded into a group chat or quoted in a tender.
Deletion removes the bytes
Removing a folder decrements the reference count on every chunk its versions used, and a chunk nothing else points at is deleted from storage. It cannot be undone by you or by us.
Where the key lives
A workspace created with encryption on is opened by a key your own tooling puts on your own Windows machines. Syncture stores its key id, which is public and says nothing about the key. There is no field in the service that could hold the key itself.
In transit and at rest
Every request between a workstation, the browser console and Syncture travels over HTTPS. There is no plaintext path across the network, and no inbound connection to a machine of yours.
Objects in storage are encrypted at rest by Cloudflare under keys Cloudflare manages. This protects them if a disk is stolen or hardware leaves a data centre. It is a separate mechanism from a workspace created with encryption on, and the two are independent of each other.
Sessions and device credentials are held only as hashes. Losing our database would not hand somebody a working credential, though it would hand them the metadata this page describes.
Where it sits, and under whose law
An account is placed in the region it was created in and does not move. European accounts hold their objects under Cloudflare's EU jurisdiction. That is a contractual guarantee that those objects do not leave the European Union, and it is a stronger thing than a bucket that happens to be in Frankfurt.
The names are covered too. Every folder and model name, every file path, the share graph and the invoices live in one database, created under Cloudflare's EU jurisdiction. That restricts it to run and store its data inside the European Union, for every account, including one whose files are kept outside Europe.
Syncture is operated from Vienna by an Austrian sole proprietor, so the business you contract with sits in the same jurisdiction as the European storage. Legal requests are answered only against valid process, and you are told about one unless we are forbidden to tell you.
Who runs it, and who can reach it
Syncture is written and operated by one person. There is no support team, no operations desk and no third party with a console into production. In a workspace created with encryption off, the people who can read a model are that person and anybody who compromises the Cloudflare account he administers.
Production access is a provider account with two-factor authentication and its own audit trail. No API token, access key or storage credential sits in configuration, in secrets, on a workstation or in a log, because none is used. A compromise of the service is a deploy, so the control that matters is who can deploy.
One person is also an availability risk, and the answer to it is the export rather than a promise. The application writes your whole account to disk in one command, and it keeps working for as long as the service is reachable. Nothing is deposited with a third party against our disappearance, and the Terms say what notice you get if the service stops.
What survives a fault
A publish never overwrites. Content is addressed by the hash of the bytes stored, so history is what the layout is instead of a feature sitting on top of it. Objects are stored redundantly inside their region.
The database carries point-in-time recovery for thirty days, which exists so the service can be restored after a fault. It is not reachable as a customer feature and nothing is restored from it on request. It is also why a deleted row can outlive the deletion by up to thirty days, which the privacy policy states rather than leaves for an auditor to find.
Nothing is deleted for non-payment. An ended plan and a finished trial both become read-only, and everything stored stays readable and exportable. Silence is the one thing that ends an account: with no paid storage and nobody signing in for twelve months, three messages go out and it closes thirty days after the last. Signing in once stops that.
What we do not keep
No trash a deleted file went to, and no copy of one the product can read back. Database rows age out of the platform's thirty-day recovery window, which is not reachable as a feature.
No storage key of yours, because there is no bucket of yours.
No key to any workspace created with encryption on, in any form.
No password. Sign-in codes are peppered hashes held for minutes.
No session token and no device secret, only hashes of them.
No hardware identifier, no IP address recorded against your account, and no record of which models anybody opened.
Nothing you publish trains anything, here or anywhere we send it.
No advertising cookie, no third-party analytics, no profile of you.
What we do not hold
ISO 27001 certification and a SOC 2 report. A questionnaire asking for either should be answered with that, and with the controls set out above it.
A penetration test by an independent firm. Nothing outside this business has tested the service, and that is the honest answer to the question.
Any way to recover a lost workspace key. That follows from the key never reaching us, and no support process substitutes for it.
An uptime figure, a service level or credits. None is agreed in the Terms and none is implied here.
A backup of your files taken by us. The Terms put that duty on you, and the export is what makes it a small one.
A second person. One person writes and operates this, and the section on who runs it says what follows from that.
Under examination
One mechanism is in evaluation. This page carries the date it becomes available, and nothing on this site describes it as delivered before then.
Storage you supply
For practices whose own obligations require models to sit in infrastructure they control. The work is in making that a supported configuration rather than an afternoon of setup a firm has to own, and it is under examination on those terms.
Reporting a vulnerability
Reports go to the address below and are acknowledged within two business days. Include the steps to reproduce, the endpoints affected, the impact you believe it has, and a way to reach you. The same details are published at /.well-known/security.txt.
We will not pursue a good-faith researcher who stays inside their own account, respects other customers' privacy, stops at the first sign of somebody else's data, and gives us reasonable time to fix the issue before publishing. Do not test against accounts you do not own. There is no paid bounty.
Filling in a security questionnaire
Write to mail@syncture.com and the answers come from the person who wrote the code. If a line on this page is not specific enough for your client's auditor, say which one and it will be made specific in writing. If a questionnaire asks for end-to-end encryption, the honest answer names the workspace it is about, and we will put that in writing.