Security

1. Security principles

Lytheron applies a risk-based approach, least privilege, separation of responsibilities and defence in depth. Measures evolve with the service, observed risks and the capabilities of providers in use.

2. Organisation isolation

Operational data is associated with an organisation. Access is controlled by identity, membership, role and product entitlement. Database-level security rules restrict reads and changes to authorised records, reducing reliance on interface checks alone.

3. Authentication and sessions

• Authentication managed through a dedicated provider.
• Passwords are not stored in plaintext by the application.
• Email confirmation, password recovery and invitations use time-limited tokens.
• Checks against token reuse and multiple acceptance.
• Sessions protected by technical cookies and controlled token renewal.

Users must use strong passwords, protect devices and immediately report suspicious access.

4. Authorisation and privileged operations

Roles and organisation membership determine permitted operations. Organisation creation, invitation management, product activation, credit consumption and other sensitive operations are executed by the backend through controlled and, where necessary, atomic functions.

• Administrative keys must not be exposed to the browser.
• Privileged functions check identity, role, organisation and product status.
• Relevant organisation operations may be recorded in audit logs.
• Sensitive changes are designed to avoid race conditions and repeated use.

5. Encryption and transport

Public connections use HTTPS/TLS. Databases, storage, backups and secrets are managed through infrastructure services applying their own encryption and protection measures. Application secrets are kept server-side or in environment-variable management systems and must not be included in public code.

6. Validation, rate limits and input protection

• Input validation before writes or sensitive operations.
• Rate limits on endpoints, public forms and abuse-exposed workflows.
• File type, size and path checks where applicable.
• Protection against unauthorised requests and API misuse.
• Separation between restricted public keys and highly privileged server credentials.

7. Payments

Full card details are collected by the payment provider and do not pass through Lytheron application databases. Checkout, renewals and the billing portal are managed by the provider. Events changing commercial status are verified, processed idempotently and associated with the correct organisation.

8. Logging, monitoring and auditing

Lytheron records technical and organisational events useful for diagnosing errors, preventing abuse, reconstructing operations and managing incidents. Log access is restricted to people and providers who need it. Logs must not contain secrets, passwords or full card details.

9. Backups, continuity and recovery

Backup and recovery capabilities depend on managed services and the active infrastructure plan. Lytheron configures procedures proportionate to data criticality and periodically checks recovery possibilities where supported.

The customer must retain copies of exportable critical content and must not use Lytheron as the sole archive of irreplaceable documents without a specific agreement.

10. Vulnerability management

Dependencies, configurations and components undergo automated checks and risk-related reviews. Fixes are prioritised by exploitability, exposure, data impact and available mitigations.

11. Incident management

During an incident, Lytheron aims to identify scope, contain risk, preserve necessary evidence, restore the service and apply corrective actions. Where an incident involves a personal data breach, notification obligations to customers, individuals and authorities are assessed according to privacy role and applicable law.

12. Providers and subprocessors

Hosting, databases, authentication, operational emails and payments are entrusted to specialised providers. Selection considers technical capabilities, security measures, contractual terms and data protection tools. Principal providers are listed on the Subprocessors page.

13. Customer's shared responsibilities

• Assign only necessary roles and promptly remove users no longer authorised.
• Protect credentials, devices, email accounts and recovery methods.
• Review published content, personal data, files and permissions.
• Correctly configure domains, integrations and external access.
• Export or retain copies of critical data according to its needs.
• Promptly report abnormal behaviour, suspicious access or vulnerabilities.

14. Responsible vulnerability reporting

If you identify a possible vulnerability, write to legal@lytheron.com with the subject “Security vulnerability report”. Include:

• the affected page, endpoint or product;
• a description of impact and necessary conditions;
• minimal, non-destructive reproduction steps;
• any screenshots or redacted requests without third-party data;
• contact details to coordinate clarification and remediation.

15. Rules for safe research

To benefit from the responsible reporting approach, act in good faith, limit testing to the minimum necessary and do not:

• access, modify, delete or retain other users' data;
• perform denial of service, spam, social engineering or physical testing;
• use malware, mass scanning or tools degrading the service;
• extend access beyond what is necessary to demonstrate the issue;
• publicly disclose the issue before allowing reasonable remediation time.

If you comply with these rules and applicable law, Lytheron will consider the research authorised solely for reporting purposes and will not take action for the simple technical circumvention necessary to demonstrate the vulnerability. This statement does not authorise unlawful activities or bind third parties.

16. Timing and communications

We seek to acknowledge valid reports within a reasonable time, assess severity and provide updates compatible with remediation work. We do not guarantee financial rewards but may publicly recognise a contribution with the researcher's consent.

17. Certifications and statements

Lytheron does not claim certifications, independent audits or compliance levels that are not expressly published and verifiable. Providers' certifications do not automatically constitute certification of the entire Lytheron service.

18. Related documents

For the complete framework, see the Privacy notice, Data Processing Addendum, Subprocessors page, Acceptable use policy and Terms of service.

Supabase infrastructure attestations

Supabase states that it holds ISO/IEC 27001:2022 certification and a SOC 2 Type 2 report within its own control scope. These attestations concern the provider; they do not certify Lytheron OÜ, application code, configuration or the complete Lytheron Cloud service. See Supabase Security. Access to the certificate and report is subject to provider terms. These attestations do not establish an uptime commitment, recovery time or exclusively European data residency for Lytheron Cloud.

Lytheron remains responsible for application controls and configurations within its remit. The provider DPA does not replace the DPA between Lytheron and its customer.