Cryptography
The primitives that encrypt, hash, authenticate, and derive keys. Standards here govern whether the underlying math is correct, well-studied, and safely implemented.
FIPS 197 — Advanced Encryption Standard (AES)
comply- What it is, in plain terms
- The U.S. government standard for symmetric encryption. AES is the block cipher that most of the internet relies on to keep stored data confidential.
- Why it matters for you
- It means the algorithm locking your data at rest is the same one used by banks, militaries, and health systems worldwide — not a homemade cipher.
- How ATROTON meets it
- We use AES-256 in GCM mode — authenticated encryption that detects tampering — as specified by FIPS 197 + SP 800-38D. A representative usage path is the TOTP-secret encryption in the server's multi-factor code; additional paths wrap server-side keys and per-object data keys.
FIPS 180-4 — Secure Hash Standard (SHA-2)
comply- What it is, in plain terms
- The standard for one-way hash functions in the SHA-2 family — primitives that turn any amount of data into a short, tamper-evident fingerprint.
- Why it matters for you
- Hashing is what makes audit trails verifiable. If a single byte of a record changes, the fingerprint changes completely; that is how you know the history has not been rewritten.
- How ATROTON meets it
- SHA-256 backs HMAC-based backup-code hashing in the multi-factor module, the proof-of-work challenge on the public landing page, and the hash format used to submit content digests to OpenTimestamps. SHA-1 is not used anywhere. (Our internal default hash family is SHA-3 — see the next entry.)
FIPS 202 — SHA-3 Standard (Keccak)
comply- What it is, in plain terms
- A second family of hash functions (Keccak / SHA-3 / SHAKE) built on a different mathematical construction from SHA-2. Two independent families exist so that if one is ever broken, the other remains safe.
- Why it matters for you
- Running two independently designed hash families is an insurance policy against future cryptographic breakthroughs.
- How ATROTON meets it
- SHA-3-256 is our default hash primitive — used for HKDF key derivation, admin-token fingerprints, and the content hashes we feed to OpenTimestamps. The Dilithium / ML-DSA and Kyber / ML-KEM post-quantum primitives also rely on SHA-3 / SHAKE internally.
FIPS 198-1 — Keyed-Hash Message Authentication Code (HMAC)
comply- What it is, in plain terms
- A construction that combines a secret key with a hash function to prove a message came from someone who holds that key and has not been altered in transit.
- Why it matters for you
- It is the primitive that stops an attacker on the network from silently changing a message without you noticing.
- How ATROTON meets it
- HMAC-SHA-256 is used to hash backup codes for constant-time verification, to sign the single-use PoW challenges on the public login page, and to produce audit-trail fingerprints. HMAC also underpins the HKDF key-derivation we use throughout (next entry).
RFC 5869 (HKDF) — HMAC-based Key Derivation
comply- What it is, in plain terms
- A standard way of turning one high-entropy secret into several unrelated keys for different purposes.
- Why it matters for you
- Reusing the same key for two different purposes is a classic way to break a cryptosystem. HKDF is the disciplined method for splitting one secret into many unlinked keys — one for encryption, one for authentication, one per session.
- How ATROTON meets it
- All symmetric key derivations go through HKDF instantiated over SHA-3-256 (RFC 5869 over FIPS 202), with explicit domain-separation labels so keys derived for different purposes from the same secret cannot be confused.
FIPS 186-5 — Digital Signature Standard
comply- What it is, in plain terms
- The U.S. standard for digital signatures — the math that lets us prove a message, token, or receipt really came from whoever holds the matching private key.
- Why it matters for you
- Signatures make session tokens, invitations, and audit entries unforgeable.
- How ATROTON meets it
- We use Ed25519 (EdDSA over Curve25519, specified in RFC 8032) for signed audit-chain entries and warrant-canary attestations. Ed25519 is deterministic: unlike the older ECDSA scheme, it does not depend on per-signature randomness and is therefore immune to the random-number failures that have leaked ECDSA private keys in the wild.
Argon2id — Memory-Hard Passphrase KDF (RFC 9106)
comply- What it is, in plain terms
- The winner of the Password Hashing Competition. A function designed to be slow and memory-hungry on purpose so that an attacker cannot crack a passphrase by renting a rack of GPUs.
- Why it matters for you
- Your passphrase protects the keys that unlock your vault. Argon2id is what makes the difference between "crackable in an afternoon" and "not feasible on any machine that currently exists".
- How ATROTON meets it
- Passphrases are stretched through Argon2id (RFC 9106) with a tuned memory/time parameter set and per-user salts. Both authentication and the derivation of the admin database encryption key go through this step — the passphrase never leaves the device unhashed.
SQLCipher — Transparent AES-256 encryption of SQLite databases
comply- What it is, in plain terms
- An open-source extension to SQLite that encrypts every database page with AES-256 and authenticates it with HMAC, using a key derived from a passphrase through a memory-hard KDF.
- Why it matters for you
- The ATROTON server stores each organisation's data in its own SQLCipher-backed vault. The master key is derived on your device from your passphrase — so even an attacker with full filesystem access to our server sees ciphertext.
- How ATROTON meets it
- Every per-organisation vault file on the server is a SQLCipher database. Page-level AES-256 encryption and HMAC integrity are enforced before any row is read or written. This is the single most load-bearing protection in our architecture.
NIST SP 800-88 — Guidelines for Media Sanitization
comply- What it is, in plain terms
- The U.S. government's guideline for how to actually destroy data — not just "move to trash", but "make it unrecoverable by a well-funded adversary".
- Why it matters for you
- On a modern cloud filesystem, deleting a file does not overwrite its bytes. NIST SP 800-88's "Purge" level is what makes erasure stick, even against someone with physical access to the disk later.
- How ATROTON meets it
- We destroy data by destroying the key that encrypted it — a technique the guideline calls cryptographic erase, which qualifies as Purge. Erasing an organisation's vault key removes ATROTON's ability to decrypt that organisation's SQLCipher database, even though the ciphertext on disk remains until normal backup-retention cycles overwrite it.
Post-Quantum Readiness
Quantum computers that can break today's public-key cryptography do not exist yet, but they are expected inside 10–15 years. "Harvest now, decrypt later" — where an adversary records today's ciphertext to decrypt after quantum hardware arrives — is already happening. Post-quantum cryptography (PQC) is math that remains safe against quantum attack.
CRYSTALS-Kyber (r3) — NIST PQC Round-3 Kyber-1024
comply- What it is, in plain terms
- A lattice-based post-quantum key-exchange algorithm. Kyber won NIST's Post-Quantum Cryptography competition in 2022 and became the basis for the finalised FIPS 203 ML-KEM standard in 2024.
- Why it matters for you
- It means a session key negotiated today cannot be retroactively recovered by a quantum computer in ten years — the realistic threat against sensitive material that has to stay confidential for decades.
- How ATROTON meets it
- We ship the round-3 submission — Kyber-1024, the highest security level — paired with classical X25519 in hybrid mode. Note: this is the round-3 algorithm that preceded the finalised FIPS 203 ML-KEM; we are tracking the migration to ML-KEM once production-grade validated implementations of the final specification are available.
CRYSTALS-Dilithium (r3) — NIST PQC Round-3 Dilithium3
comply- What it is, in plain terms
- A lattice-based post-quantum signature algorithm. Dilithium is the signature counterpart to Kyber and became the basis for the finalised FIPS 204 ML-DSA standard in 2024.
- Why it matters for you
- Signatures on long-lived records — audit entries, query receipts, viewer attestations — need to stay unforgeable for as long as the records themselves matter. Classical-only signatures do not clear that bar against a future quantum adversary.
- How ATROTON meets it
- We ship Dilithium3 (the mid-security level with 128-bit post-quantum security), hybridised with Ed25519. The immediate use is on cryptographic query receipts and viewer receipts (per-query and per-access audit entries, Merkle-chained and anchored to Bitcoin via OpenTimestamps). As with Kyber, this is the round-3 ancestor of the finalised FIPS 204 ML-DSA; migration is tracked.
RFC 7748 — Curve25519 / X25519 Key Agreement
comply- What it is, in plain terms
- The modern elliptic curve used for Diffie–Hellman key exchange. Fast, constant-time, designed to resist implementation mistakes that broke older curves.
- Why it matters for you
- Even in a post-quantum world we keep the classical curve in the mix — if the new lattice math ever has a surprise flaw, your traffic is still protected by the well-studied 25519 layer underneath.
- How ATROTON meets it
- X25519 is the classical half of our key-agreement primitive and is always paired with Kyber/ML-KEM in hybrid mode.
Transport Security
The standards that keep data safe while it is travelling between your device and our server — how TLS is configured, which certificates are trusted, and how certificate issuance is logged publicly.
RFC 8446 — TLS 1.3
comply- What it is, in plain terms
- The current generation of Transport Layer Security — the "S" in HTTPS. TLS 1.3 removed every legacy option that was responsible for a decade of attacks on older versions.
- Why it matters for you
- It is the difference between "secure on paper" and "actually secure in the field". TLS 1.3 refuses to negotiate any of the compromised options that let attackers downgrade older connections.
- How ATROTON meets it
- TLS 1.3 is offered on the public edge (nginx serving atroton.com). Real connections are observed negotiating TLS_AES_256_GCM_SHA384. TLS 1.2 remains supported as a transitional fallback for older clients; TLS 1.0 and 1.1 are refused — see the next entry.
RFC 8996 — Deprecating TLS 1.0 and TLS 1.1
comply- What it is, in plain terms
- The IETF decision that formally retires the old TLS 1.0 and 1.1 protocols. No modern platform should still accept them.
- Why it matters for you
- A server that still accepts TLS 1.0 can be tricked into negotiating it against a modern client. Refusing it outright closes that attack.
- How ATROTON meets it
- The nginx edge configuration explicitly enumerates only TLS 1.2 and TLS 1.3; TLS 1.0 and TLS 1.1 are neither listed nor negotiable. There is no compatibility fallback to them.
NIST SP 800-52 Rev 2 — Guidelines for TLS Implementations
comply-selective- What it is, in plain terms
- NIST's detailed rulebook for configuring TLS — which protocol versions, which cipher suites, which key sizes are acceptable.
- Why it matters for you
- Even the right protocol version can be configured wrong. This is the checklist that ensures a TLS deployment is actually as strong as its version number suggests.
- How ATROTON meets it
- The subset we meet today: TLS 1.3 offered with AEAD suites only, TLS 1.0 / 1.1 refused, certificates issued via ACME (Let's Encrypt) and automatically published to multiple Certificate-Transparency logs. Items still on the roadmap — HSTS-preload, OCSP stapling, CAA DNS records, and the full Mozilla "Modern" cipher-suite restriction — we will list here only once they are live.
RFC 5280 — X.509 Public-Key Infrastructure
comply- What it is, in plain terms
- The certificate format that the web runs on. X.509 defines how identities (like "atroton.com") are bound to public keys, and how browsers check that the binding is authentic.
- Why it matters for you
- It is what makes the padlock icon in your browser mean something — without X.509 validation, an attacker on the network could substitute their own key for ours without you noticing.
- How ATROTON meets it
- Certificates for atroton.com are issued through Let's Encrypt via ACME (RFC 8555), renewed automatically well before expiry, and published to public Certificate-Transparency logs (RFC 9162 / LE policy) so unauthorised issuance would be visible.
RFC 8032 (EdDSA) — Ed25519 signatures
comply- What it is, in plain terms
- The IETF specification for the Ed25519 signature algorithm — deterministic, collision-resilient signatures over Curve25519.
- Why it matters for you
- "Deterministic" matters: older signature schemes (ECDSA) have produced catastrophic key leaks when their random-number generators failed. Ed25519 does not rely on per-signature randomness and is immune to that class of failure.
- How ATROTON meets it
- Ed25519 is the classical-signature counterpart we use alongside Dilithium / ML-DSA — for audit-chain checkpoints, warrant-canary attestations, and SSH host access.
Authentication & Identity
How we know whoever is sending a request is who they claim to be. Our public login page uses proof-of-work + username lookup, passphrase, and TOTP-based second-factor. Phishing-resistant hardware-passkey login (WebAuthn / FIDO2) is on the roadmap and will be listed here when it ships.
NIST SP 800-63B — Digital Identity — Authentication (AAL2)
comply- What it is, in plain terms
- The U.S. government's standard for how strong an authentication has to be. "Authenticator Assurance Level" 1 is weakest (password alone), 2 is multi-factor, 3 is hardware-bound and phishing-resistant.
- Why it matters for you
- It fixes the bar for what "multi-factor" actually requires — not just "another code by SMS", but a second factor that is bound to something only the user possesses.
- How ATROTON meets it
- Every authenticated user is required to complete AAL2: passphrase plus a TOTP (RFC 6238) authenticator enrolled in the multi-factor module. Session duration and re-authentication windows follow the AAL2 limits. AAL3 phishing-resistant passkey authentication is a planned upgrade; it is not listed as compliant here today because the WebAuthn path is not yet shipped.
Privacy & Data Protection
Legal and technical standards that govern what personal data we can collect, for what purpose, for how long — and how we let you get it back or erase it.
GDPR Art. 25 — Data Protection by Design and by Default
comply → exceed- What it is, in plain terms
- The article of GDPR that elevates privacy from a best practice to a legal requirement — systems must be designed from the start so that personal data is minimised, protected, and only accessible where strictly necessary.
- Why it matters for you
- It is the difference between a product that bolts on a privacy policy and a product where the architecture itself cannot misuse your data.
- How ATROTON meets it
- The server is treated as an untrusted relay: it stores ciphertext in SQLCipher vaults, routes messages, and enforces access-control on opaque blobs. The admin-DB key is derived on the operator's device from their passphrase; the organisation-vault keys derive on authenticated sessions — neither is persisted in the clear.
GDPR Art. 32 — Security of Processing
comply → exceed- What it is, in plain terms
- The GDPR article that requires controllers and processors to implement "appropriate technical and organisational measures" for the security of personal data — encryption, integrity, resilience, and the ability to test these measures.
- Why it matters for you
- It is what makes "we take security seriously" a legal undertaking with teeth, not a marketing line.
- How ATROTON meets it
- Every content-bearing surface is encrypted with AES-256-GCM or within a SQLCipher vault. Integrity is authenticated through AEAD and HMAC. Keys are derived from user passphrases via Argon2id and HKDF-SHA-3. The engineering bar is set substantially above the statutory baseline.
GDPR Art. 17 — Right to Erasure (Right to be Forgotten)
comply- What it is, in plain terms
- The GDPR right that lets a person require a controller to delete their personal data under specified conditions.
- Why it matters for you
- On most cloud services, "delete" really means "hide, but the bytes are still on a disk somewhere and in several backups". That is not erasure.
- How ATROTON meets it
- Each organisation's vault is encrypted under a key that only the organisation holds. When an organisation's vault key is destroyed, the ciphertext on our disks is unrecoverable even to us. This is the "Purge"-level cryptographic-erase technique called out in NIST SP 800-88.
GDPR Art. 30 — Records of Processing Activities
comply- What it is, in plain terms
- The GDPR requirement that every controller and processor keep a written record of what categories of personal data they process, why, on whose behalf, and for how long.
- Why it matters for you
- When a regulator or a customer asks what we do with your data, the answer has to be a document, not a sentence on a landing page.
- How ATROTON meets it
- A per-tenant Record of Processing Activities is generated for every organisation, listing purposes, data categories, retention windows, and any sub-processors involved. Publishing the public Article-30 register is on our Q3-2026 roadmap; the internal record exists today.
ISO/IEC 27018 — PII Protection in Public Clouds (as a Processor)
comply → exceed- What it is, in plain terms
- The international standard for how a cloud provider should handle personal data when it acts as a processor on behalf of a customer.
- Why it matters for you
- It is the yardstick large buyers use to check whether a cloud can be trusted with personal data at all.
- How ATROTON meets it
- The standard asks for strong access-control on personal data. Our architecture goes further: because the data is encrypted under keys the server cannot derive in isolation, personal data is structurally inaccessible to ATROTON staff and to any process subpoenaed on our infrastructure — not merely access-controlled.
Governance, Risk & Frameworks
The management-system and control-catalogue standards that organise how we identify risks, implement controls, monitor them, and respond when something goes wrong.
NIST CSF 2.0 — NIST Cybersecurity Framework 2.0
comply- What it is, in plain terms
- The U.S. government's umbrella model for organising a cybersecurity programme around six functions: Govern, Identify, Protect, Detect, Respond, Recover.
- Why it matters for you
- It is the common vocabulary auditors and large buyers use to compare security programmes.
- How ATROTON meets it
- Every one of the six functions has documented owners, controls, and evidence: risk register, asset inventory, incident-response runbooks, audit pipeline, disaster-recovery plan. The founder is the accountable officer for the Govern function today, with a CISO role planned as we scale.
NIST SP 800-53 — Security and Privacy Controls (Rev 5)
comply-selective- What it is, in plain terms
- The master catalogue of security and privacy controls for U.S. federal information systems — organised into families like Access Control, Audit, Identification & Authentication, System & Communications Protection.
- Why it matters for you
- Almost every U.S. compliance regime (FedRAMP, CMMC, FISMA) is ultimately a selection and overlay of SP 800-53 controls.
- How ATROTON meets it
- The Access Control (AC), Audit (AU), Identification & Authentication (IA), and System & Communications Protection (SC) families are covered at a level that meets or exceeds the Moderate baseline. Full Moderate-baseline self-assessment is a roadmap item we are honest about rather than a present claim.
NIST SP 800-207 — Zero-Trust Architecture
exceed- What it is, in plain terms
- "Never trust, always verify." No request gets a free pass just because it is coming from inside a firewall — every request authenticates and is authorised against the resource it is asking for.
- Why it matters for you
- Most breaches happen after the perimeter has been crossed. Zero-Trust architectures assume the perimeter is already breached and rely on per-request authentication to contain the damage.
- How ATROTON meets it
- The application treats its own server as untrusted relative to client content — a posture stricter than 800-207 requires. Every API call authenticates at the cryptographic layer, every authorisation is evaluated against identity, resource sensitivity, and action risk. There is no "internal" network that bypasses these checks.
NIST SP 800-218 (SSDF) — Secure Software Development Framework v1.1
comply- What it is, in plain terms
- The U.S. government's checklist for how software should be built: threat-modelling before code, secure defaults, peer review, dependency scanning, incident response — with evidence that all of it actually happens.
- Why it matters for you
- It addresses the category of breach where the software itself was built insecurely, long before any attacker got involved.
- How ATROTON meets it
- Every feature is threat-modelled before implementation; code is peer-reviewed; dependencies are policed through a repository-enforced allow/deny policy file; memory safety is guaranteed by writing the server in Rust. Publishing the SSDF self-attestation per release is a roadmap item we track.
CIS Controls v8.1 — Critical Security Controls
comply- What it is, in plain terms
- The Center for Internet Security's "if you only do eighteen things, do these" list. Prioritised, specific, and the single best starting checklist for a defensible security programme.
- Why it matters for you
- It is the compact, actionable version of the bigger control catalogues — easier to audit against and easier to demonstrate progress on.
- How ATROTON meets it
- Implementation Group 2 (IG2) is fully covered. IG3 (advanced) items still in progress — notably application-layer firewalls and formal penetration-testing cadence — are tracked on our roadmap.
MITRE ATT&CK — Adversary Tactics, Techniques & Common Knowledge
comply- What it is, in plain terms
- MITRE's catalogue of how real attackers actually behave in the wild — organised into tactics (goals) and techniques (how they reach them).
- Why it matters for you
- It shifts the conversation from "what controls do we have" to "which specific attacker behaviours do those controls actually stop".
- How ATROTON meets it
- Detection and mitigation are mapped against the ATT&CK Enterprise and Cloud matrices. Several technique classes are architecturally impossible on our system — there are no server-decryptable secrets to steal (T1552) and no password store to exfiltrate (T1555), because credentials do not live on the server in recoverable form.
CISA KEV Catalog — Known-Exploited Vulnerabilities Catalog
comply- What it is, in plain terms
- The live list, maintained by the U.S. Cybersecurity and Infrastructure Security Agency, of vulnerabilities known to be actively exploited in the wild — not just theoretical weaknesses.
- Why it matters for you
- Patch queues are endless. KEV tells you which of those patches actually matter this week because attackers are using them right now.
- How ATROTON meets it
- Components touched by a KEV advisory are patched against an explicit service-level target: critical-severity KEVs within 72 hours, high-severity within 7 days. Automating the KEV-ingest-to-ticket pipeline is a Q3-2026 roadmap improvement.
HIPAA — HIPAA Security Rule (45 CFR Part 164)
comply → exceed- What it is, in plain terms
- The U.S. rule that governs how protected health information must be secured, whether by a healthcare provider, an insurer, or a vendor acting on their behalf.
- Why it matters for you
- It is the law that determines whether a healthcare organisation can put health data on our platform at all.
- How ATROTON meets it
- As a Business Associate we can sign a BAA with any covered entity. Where HIPAA treats encryption as "addressable" (i.e. optional with a written justification), our architecture makes it structural and unavoidable — even ATROTON operators cannot decrypt the data. Multi-factor authentication is universal and audit logging exceeds the §164.308 minimum. A 2024 NPRM tightens HIPAA toward mandatory encryption; we already exceed that direction.
ISO/IEC 27002:2022 — Information Security Controls — Reference
comply-selective- What it is, in plain terms
- The international reference catalogue of 93 information-security controls, organised into four themes (organisational, people, physical, technological). The companion to ISO/IEC 27001.
- Why it matters for you
- If you are comparing us against another vendor under a 27001-style rubric, this is the control list they are scoring against.
- How ATROTON meets it
- We use 27002:2022 as the control-selection reference for our Statement of Applicability. Every applicable control has an owner and an evidence artefact. The 27001 certification itself is on our attestation roadmap — not claimed here until obtained.
ISO/IEC 27017 — Information Security Controls for Cloud Services
comply-selective- What it is, in plain terms
- The cloud-specific extension to 27002 — controls that only make sense when one party is providing a cloud service to another.
- Why it matters for you
- It covers the shared-responsibility boundary: which security tasks belong to the cloud provider, which belong to the customer, and which to both.
- How ATROTON meets it
- We apply the 27017 overlay from both sides: as a cloud customer of our underlying infrastructure provider, and as a cloud service provider to our own customers. The shared-responsibility matrix is documented and reviewed quarterly.
EU NIS2 — NIS2 Directive (EU 2022/2555)
comply-selective- What it is, in plain terms
- The EU's second-generation network-and-information-security directive. It sets a cybersecurity baseline — risk management, incident reporting, supply-chain security — for "essential" and "important" entities across the EU.
- Why it matters for you
- If your organisation falls under NIS2, your vendors and service providers have to hold up their end of it.
- How ATROTON meets it
- Risk management, supply-chain security, and incident-response runbooks are in place at a level that supports NIS2-covered customers. Article-23 incident notification SLAs (24 hours / 72 hours / one month) are engineered into our incident-response process so a customer can meet their regulator's clock without waiting on us.
EU DORA — Digital Operational Resilience Act
comply-selective- What it is, in plain terms
- The EU regulation that requires banks, insurers, investment firms, and their ICT providers to demonstrate that they can keep running — and recover — through a cyber incident.
- Why it matters for you
- If you are a supervised EU financial entity, DORA makes your critical ICT providers extensions of your own compliance obligation.
- How ATROTON meets it
- ICT risk-management, incident-reporting, and register-of-information support are designed in. Contractual DORA annexes are on the short-term roadmap as financial-sector customers onboard. Threat-led penetration testing (TLPT) is a 2027 target we are honest about.
EU AI Act — Regulation (EU) 2024/1689 on Artificial Intelligence
comply-selective- What it is, in plain terms
- The EU's risk-tiered law on AI. Some uses are banned outright, some are high-risk and heavily regulated, most everyday uses are "limited-risk" and carry transparency duties.
- Why it matters for you
- It regulates how AI features must disclose what they are doing with your data and how they reached their outputs.
- How ATROTON meets it
- ATROTON ships no Annex-III high-risk AI — no biometric categorisation, no social scoring, no automated decisions with legal effect. AI-chat features are limited-risk and carry transparency notices. Any AI feature sees only ciphertext of user content, by the same architecture that governs everything else.
Application Security
Standards that govern the security of the application code itself — verification checklists and the "most common mistakes" list that every web application has to clear.
OWASP ASVS v5 — Application Security Verification Standard
comply- What it is, in plain terms
- OWASP's comprehensive verification checklist for web applications. Level 1 is the basic bar, Level 2 is "enterprise", Level 3 is the bar used for systems where a breach would have outsize consequences.
- Why it matters for you
- It is the single most direct way to ask an application: "have you handled the cryptography, access control, input validation, logging, and business-logic issues that actually get shipped broken?"
- How ATROTON meets it
- Server-side code is designed to the ASVS Level 3 bar; the user interface is held to at least Level 2. Memory-safety items come free from writing the server in Rust. CI-enforced ASVS-Level-3 verification is a Q3-2026 roadmap item; most individual requirements are satisfied today.
OWASP Top 10 — Top 10 Web Application Security Risks
comply- What it is, in plain terms
- The ten most common classes of mistake in web applications — broken access control, cryptographic failures, injection, insecure design, and so on.
- Why it matters for you
- Most real-world breaches still fall into one of these buckets. The Top 10 is the minimum bar every web application has to clear.
- How ATROTON meets it
- All ten categories have specific mitigations: attribute-based access control, memory-safe Rust, parameterised queries, authenticated encryption by default, and a structured audit pipeline covering the Logging & Monitoring category.
About this page
This list is generated from a single internal source of truth: ATROTON's security-standards matrix, which scores every relevant standard against five possible statuses:
- comply — we meet the bar today.
- exceed — we deliberately go beyond it.
- comply-selective — we meet the subset that applies to our architecture.
- aspirational — explicit target, not yet achieved.
- N/A — structurally inapplicable.
Only entries marked comply, exceed, or comply-selective and substantiated in shipped code appear on this page. If a standard you expected to see here is missing, it is because we have not yet met the bar, and we will not pretend otherwise.
Specific things we are not claiming today — and why: FIPS 140-3 certification (CMVP submission not filed); SOC 2 / ISO/IEC 27001 / 27701 / 42001 (no auditor engaged yet); SLSA build-track and Sigstore release-signing (workflow configured, no tagged release yet); RFC 9180 HPKE, RFC 3394 AES-Key-Wrap, RFC 9420 MLS, RFC 3161 TSA (not in shipped code); ChaCha20-Poly1305 AEAD (not used in shipped code); WebAuthn L3 / FIDO2 / CTAP2 passkey sign-in (planned; we use TOTP-based AAL2 today); TPM 2.0, UEFI Secure Boot, LUKS2 full-disk encryption (the current Hetzner host exposes none of these — the migration path is tracked in our infrastructure-hardening plan); eIDAS 2.0, BSI C5, TIBER-EU (aspirational per our matrix); NIST SP 800-171 / 800-193 (not yet substantiated). Each of these chips will be honestly added to the public ticker and to this page the day the underlying implementation lands.
Visitors can consume the structured equivalent of this page at /compliance.json. The canonical security-standards matrix itself is held internally and shared under NDA for procurement review.
No standards match that search. Try a broader term — for example , , , or .