Is data on XNS encrypted at rest?

Yes, always, with no setting to disable it and no premium tier required to enable it. Objects are also erasure-coded and spread across independent hosts, so no single host holds a readable copy of your data.

Does XNS hold keys that can read my data?

No. You run the Relayer gateway on your own host and domain, and it issues, scopes and revokes the access keys. There is no XNS-held credential that reaches your buckets.

What is XNS responsible for and what am I responsible for?

You operate the gateway container, its host, its domain and TLS certificate, your credentials, your firewall and your retention settings. XNS operates the storage network itself: host contracting, shard placement, continuous repair, and always-on encryption at rest.

How do I report a security issue to XNS?

Contact the team through xns.tech/contact. Good-faith reports are welcomed and worked with the reporter rather than treated as hostile.

Trust & security

Everything you would ask us, published before you ask.

Start from the fact that decides most of these questions: the endpoint runs on your host, so XNS holds no key to your objects and keeps no record of your bucket names. What follows is the encryption model, the durability math, the identity surface, the test results and the way to reach us about a security issue — no mutual NDA, no questionnaire round-trip, no call with an account team.

Encrypted at rest, always on Your gateway, your domain, your certificate Compatibility results published operation by operation Your keys, revocable by you

Where we stand

Two questions, and only one of them is about policy.

Most vendor security reviews are an attempt to establish what a provider would do — the policies, the training, the access controls, the promise that staff do not browse customer data. Those questions matter and we answer them below. But they are all downstream of a structural question that is usually not asked because, with every other provider, the answer is fixed: what is the provider physically able to do?

Ours is different, and it is the reason this page exists. The S3 endpoint — where objects are encrypted, keys are held, bucket names are resolved and every request is written down — runs on your host, not ours. We do not hold the key material needed to read an object. We do not receive bucket names, object keys or access times; the complete list of what our systems do receive is published on the metadata page. And the storage operators holding your shards hold neither a key nor enough of any object to reconstruct it.

That does not make the policy questions irrelevant. It makes them smaller, which is the point: the narrower the set of things we could do, the less of your review has to rest on trusting us.

What we publish

The five things a security review actually asks about

Each links to the page that answers it in full. We publish these because the alternative — asking a buyer to take our word for it — is what we would refuse in their position.

Encryption

Data is encrypted at rest across the storage network by default, with no setting to switch it off and no premium tier that turns it on. Objects are erasure-coded and distributed, so no single host holds a readable copy of your data.

How encryption works →

Durability

The redundancy scheme, the repair loop and the arithmetic behind the durability figure, written out rather than asserted — including what happens as hosts leave the network and how quickly shards are rebuilt.

Read the durability model →

Identity and access

You run the gateway, on your domain, with your certificate. It issues the access keys, scopes them per bucket or per tenant, and revokes them on your command. There is no XNS-held key that reaches your data.

Access control and identity →

Auditability

The gateway keeps an audit log of API activity on infrastructure you control, and exposes health, placement and repair state through its monitoring views rather than through a status page you have to believe.

The audit log →

Tested behavior

S3 API behavior is published operation by operation, with the same operation on AWS S3, Ceph, MinIO, Wasabi, Backblaze B2 and Storj beside it. Where we differ from Amazon, the difference is on the page.

S3 compatibility matrix →

Operational posture

How the service is built and run, what is hardened by default, and what stays your responsibility because it runs on your host — the split stated plainly so nobody discovers it during an incident.

Security posture →

Responsibility

Who operates what

XNS is not a console you log into with your data on the other side of it. You run the gateway. That changes where the boundary sits, and it is worth being explicit about the whole line rather than the convenient half.

Area	You operate	XNS operates
API endpoint	The gateway container, its host, its domain and its TLS certificate	The gateway software and its releases
Credentials	Issuing, scoping and revoking your access keys	Nothing — no XNS-held key reaches your buckets
Data at rest	Choosing what you store and your retention settings	Encryption, erasure coding, placement and continuous repair
Network	What you expose the gateway to, and your own firewall	The storage network, host contracting and node health
Monitoring	Watching your gateway's health and audit views	Network-wide durability, repair and placement

Reporting a security issue

If you have found something, tell us directly and we will work it with you. We would rather hear it from you than read about it later, and we do not treat a good-faith report as a hostile act.

Reach the team →

Who holds the encryption keys

The question a security review reaches after “is it encrypted.” Answered here rather than left for you to find out during a pilot.

The key is derived on your gateway and never sent to us.

Your Relayer derives its storage encryption key from that node’s own master secret. The key material stays on the host you run. No XNS system holds it, and no storage provider holds it — providers receive encrypted shards and nothing else. Encryption is always on, with no setting that turns it off and no tier that turns it on.

Customer-supplied keys are not accepted today.

Requests carrying SSE-C headers, and PutBucketEncryption with aws:kms, are rejected with 501 NotImplemented. There is no integration with an external KMS or HSM. If your control set requires key material you supply and hold, or documented rotation evidence for a key you own, XNS does not meet it today. We would rather you knew that here than at a 501 three weeks in.

Credentials are a separate thing, and those are yours.

Access keys are issued, scoped per bucket or per tenant, and revoked by you on your own gateway. Revocation takes effect on the next request. There is no XNS-held credential that reaches your buckets.

Read the operation-by-operation detail on the S3 compatibility matrix, which lists every encryption call and what it returns.

Bring the question your review actually turns on.

If a framework or an auditor names something specific and it is not on this page, ask before you evaluate rather than after. A straight answer costs us one email and saves you a month.

Ask us a direct question

Read the production-readiness page

Explore the platform

The full platform

Everything you need to go from evaluation to production.

How it works →The Relayer, erasure coding, and your Virtual Private Datacenter.S3 compatibility →Head-to-head S3 feature matrix vs the field.Eleven nines →Durability, computed — not rounded up.What's new →Everything built since you last looked.Releases →Every build, newest first — what changed and when.

Claims on this page last verified September 7, 2026