Security Overview
How LeraLink protects installations, accounts and content, on one page, including what is not yet in place.
Last updated: 13 November 2026
Summary
| Area | In place today |
|---|---|
| Accountability | SSStudio, trading as LeraLink |
| Hosting | Cloudflare; databases, files, configuration and job queues stored in Cloudflare's EU jurisdiction since 3 November 2026. Email by Resend; AI models from Cloudflare, OpenAI and Google, tried in a fixed order set by the platform |
| Isolation | Every request resolved to one installation; access decided on the server; cross-installation requests fail closed |
| Sign-in | One-time email codes, no passwords; passkeys required for platform administration since 3 November 2026 and available for installations' administration; administration also behind Cloudflare Access |
| Restricted content | Readable only by the people and roles named; never read by any AI model |
| Change management | Staging first, owner approval before production, automated checks on every change, rollback possible |
| Audit | Append-only audit record of changes to people and permissions, under legal hold |
| Backup | Nightly checksummed database backup kept 30 days in the EU, plus point-in-time restore; restore tested |
| Disclosure | Coordinated Vulnerability Disclosure policy and /.well-known/security.txt on every address |
| Not yet done | No independent penetration test, no certification, no single sign-on, passkeys not yet required for every installation |
Governance and accountability
SSStudio, trading as LeraLink, is the single accountable owner for security and privacy. SSStudio decides on security measures, approves every change to production, holds the administrative access to the platform and handles incidents and reports.
Security work is tracked in a risk register with priorities and release gates. A risk that blocks a stage of the pilot is closed with recorded evidence before that stage begins.
The contractual description of these measures is in the Technical and Organisational Measures, which forms part of the Data Processing Agreement.
Architecture
LeraLink runs on Cloudflare: application code, databases, file storage, configuration, job queues, coordination and search index. There is no other hosting provider and no external database. Email is delivered by Resend. AI tasks use models from Cloudflare, OpenAI and Google (see Suppliers). Each task tries its models in a fixed order set by the platform; an installation's administrators can see that order, with each provider, on the page 'AI in this installation'.
Since 3 November 2026, the databases, files (images, audio, documents, export packages and backups), configuration and job queues are stored in Cloudflare's EU jurisdiction. Requests are processed on Cloudflare's global network, usually in the data centre nearest the reader. Some processing is outside the EU: the search index, short-lived caches, anonymous reading statistics, AI processing and email delivery records. Where Your Data Is Stored lists each of these. In short: data is stored in the European Union; it is processed on Cloudflare's global network.
Installation isolation and authorisation
Each organization or person runs an installation: a separate knowledge site with its own members, content and settings. Installations share the platform's code and infrastructure, and are separated in software.
- Every request is resolved to exactly one installation from the address it was sent to. Nothing in the application is written for one particular installation.
- Every access decision is made on the server by one evaluator. It considers who is asking, their membership of that installation, their roles and grants, explicit denials (a denial always wins) and expiry dates.
- A request that would reach another installation's data is refused. When a check cannot be completed, the answer is a refusal, not access.
- A feature that is not enabled for an installation does not exist on the server for that installation. It is not only hidden in the interface.
- An installation never sees which other installations a person belongs to.
- The last owner of an installation cannot be removed, so an installation cannot be left without an accountable owner.
- Every change to people and permissions is written to the audit record.
The full list of protected actions is checked against the authorization rules by an automated test on every change.
Identity and sign-in
- Readers, members, authors and contributors sign in with a one-time code sent by email. There are no passwords to steal or reuse. A code works once and expires within minutes.
- Administrators can sign in with a passkey (WebAuthn). It is required for platform administration since 3 November 2026, and an installation can require it for its own administration; until it does, its administrators can still sign in with an email code. A passkey is phishing-resistant and bound to the exact administration address. When an installation requires passkeys, email codes are refused for its administration, and sensitive actions (access changes, ownership, domains, exports, maintenance and incident mode, key management) ask for the passkey again if it was not used in the last five minutes. A first passkey can only be added through a single-use enrollment link issued by another authorized person, never from an email-code session alone.
- Administration surfaces are additionally protected by Cloudflare Access (Zero Trust).
- Sessions have fixed limits, shorter for administrators. Session cookies are __Host- prefixed, HttpOnly, Secure and SameSite=Lax. The server stores only a hash of each session token. IP addresses and browser descriptions are stored only as keyed hashes.
Signing In and Account Security gives the session limits and the details of each method.
Restricted content
An author with proper access can restrict a Piece, or a whole Project, to named people or roles. A restricted Piece is then readable by those people and by nobody else, through any page, feed, search, export or file address. Anyone else receives the same answer as for a Piece that does not exist.
No AI model ever reads a restricted Piece. It is excluded from translation, suggestions, image generation, the knowledge layer and the search index; if a previously public Piece becomes restricted, its search index entries are removed within minutes.
Restriction is access control, not end-to-end encryption. The platform administrator and the installation owner can technically reach the database, and backups hold restricted content for 30 days like all other data. A Piece that was once public may still be held in readers' browsers or by third parties who fetched it.
Encryption
- All traffic uses HTTPS. HTTP Strict Transport Security (HSTS) is set, so browsers do not fall back to unencrypted connections.
- Stored data in Cloudflare's databases and file storage is encrypted at rest by Cloudflare, using AES-256 (with AES-GCM as the preferred mode), and management of the encryption keys is handled completely by Cloudflare's internal infrastructure.
- Session tokens are stored only as hashes. IP addresses and browser descriptions are stored only as keyed hashes.
- LeraLink does not offer customer-managed encryption keys.
Secrets
- Credentials for Cloudflare, AI providers and email delivery are held as encrypted secrets in the hosting and deployment environments. They are never stored in source code.
- Production deployment credentials can only be used by a deployment the owner has approved.
- An administrator who adds an AI provider refers to its key by name; the key itself is not shown back, and the platform's own credentials cannot be selected for a provider.
- Where a secret may have been exposed, it is replaced, and the old one is revoked.
Secure development and change management
- Source code is kept in a private GitHub repository. The main branch is protected.
- Every change goes first to a separate staging environment with its own databases, also in the EU jurisdiction.
- A change reaches production only after the owner approves the release in GitHub.
- Automated checks run on every change: behavior tests, a check of every protected action against the authorization rules, a public-artifact check and a translation coverage check.
- The public-artifact check confirms on every build that what browsers and crawlers can fetch contains no source maps, no internal dictionaries, no comments in built pages, and that error messages carry no internal detail.
- Security headers are set on every response, including HSTS, X-Content-Type-Options: nosniff and a Content Security Policy.
- Content from other services (YouTube, Vimeo, X and other external media) loads only after the reader allows it.
- Any release can be rolled back to the previous version. A change to the database structure is recorded with a restore point before it is applied.
Logging, monitoring and audit
- Audit record. Changes to people, roles, grants, ownership, domains, incident and maintenance modes and other administrative acts are written to an append-only audit record. It cannot be edited through the product and is kept under legal hold, also after an account is deleted. The Data Retention Schedule explains what that means.
- Service logs. The platform writes structured operational logs to Cloudflare for diagnosis. They are kept for a short period by Cloudflare.
- Monitoring. An internal monitor checks the service every 15 minutes. The public status page, status.lera.link, is run on GitHub, independently of LeraLink's main platform, and shows the state of the platform as a whole. See Availability and Status document for more.
Vulnerability disclosure
We welcome reports from security researchers. The Coordinated Vulnerability Disclosure policy explains how to report, what is in scope and how we respond. Every LeraLink address publishes /.well-known/security.txt with the reporting contact, security@lera.link.
Backup and recovery
- A logical backup of the whole database is made every night, checksummed and kept for 30 days in the EU.
- Cloudflare's point-in-time restore can return the database to a moment before a destructive change.
- Restore is a tested tool. On a copy of production, a full database restore took 24 minutes on 31 October 2026. The move to the EU on 3 November 2026 was itself a full restore of 271,032 rows, with every count matching.
Backup and Recovery gives the details, the recovery objectives and the limits.
Incident response
There is a written incident procedure. The platform can put one installation, or the whole platform, into read-only mode within minutes, so that reading continues while nothing can be changed. Evidence is preserved and the audit record is never deleted.
Where personal data is affected, we inform installation customers without undue delay and within 48 hours of becoming aware of a breach affecting their data, as set out in the Data Processing Agreement. Incident Response and Notification describes the whole process. To report a suspected incident, write to security@lera.link.
Suppliers
LeraLink uses a small number of suppliers: Cloudflare (hosting, storage, DNS, AI models), GitHub (code hosting, status page and certain maintenance operations), Resend (email delivery), OpenAI and Google (AI models), and DotNet Talk AB (continuity partner, with standing access to the source repository and the Cloudflare account, without Superadmin access). Each is listed, with its role, location and safeguards, in Subprocessors and Recipients. Changes are announced in advance under the Change Notification Policy.
What we have not done yet
| Gap | Status |
|---|---|
| Independent penetration test | Not yet carried out; one is planned. Internal reviews and automated checks are not a substitute for it. |
| Certification (ISO 27001, SOC 2 or similar) | None held. Security Documentation and Assurance explains what evidence we can provide instead. |
| Single sign-on (SAML or OpenID Connect) for organisations | Not available yet. No plan for it yet. |
| Passkeys | Required for platform administration since 3 November 2026, and for some installations. Not yet required for every installation's administration. |
| Hardware security keys | Not yet tested with LeraLink. |
| Support and incident response | Support is provided during office hours; there is no 24/7 support desk. Incident monitoring and incident response run around the clock. Business Continuity describes the continuity partnership with DotNet Talk AB. |
| Formal accessibility audit | Not yet carried out; see the Accessibility Statement. |
Contact
Security questions and reports: security@lera.link. Privacy questions: privacy@lera.link.