Security at Ahmedonics

Our approach

Security is a requirement, not a feature. The Hub holds client files, engineering records, invoices, payroll and signed documents, and the products we ship carry our signature into other people's systems, so the controls below were designed in from the first database schema rather than added later. They protect our own data and our clients' data alike, they are written down in the codebase, and every route is covered by a security test that runs before every deployment. What follows is a plain account of what is in place; the last section is equally plain about what is not.

Data in transit and at rest

• Everything is served over HTTPS, and browsers are told to insist on it (HSTS).
• Passwords are hashed with Argon2id and are never stored or logged in clear.
• Integration credentials, two-factor secrets and signing keys are encrypted at rest with AES-256-GCM under a key that lives only in the server's environment, never in the code or the database.
• Session identifiers, API tokens, share-link tokens, licence keys and activation tokens are stored only as hashes: a copy of the database yields none of them.
• Uploaded files are kept outside the web root under random names, with the original name only in the database, and are streamed only after the request has been authorised. Every version is checksummed on upload and nothing is ever overwritten.

Access control

• Permissions are role-based, with record-level rules on top: a client sees only the projects, files, invoices and tickets shared with them, and staff see what their role allows. A record you may not see answers as if it did not exist.
• Two-factor authentication with any authenticator app is available to every account, recommended to everyone and can be made mandatory for chosen roles. Recovery codes are shown once and stored hashed.
• Sessions time out when idle and have an absolute limit; you can see your active sessions and recent sign-in attempts under My account and sign the others out. Changing or resetting a password, disabling an account or changing its role ends its sessions.
• Sign-in, password reset and every public form are rate-limited by address, by account and site-wide, so a distributed attack meets the same wall as a single machine; when an account is locked by repeated failures, its owner is told.

Application security

• A strict Content-Security-Policy with no inline scripts or styles, plus the usual protective headers: no framing, no MIME sniffing, a conservative referrer policy and switched-off browser features we do not use.
• Every state-changing request in the Hub carries a per-session CSRF token; public forms carry a signed, time-bound token, a honeypot and, when enabled, Cloudflare Turnstile.
• All input is validated against explicit rules, all database access uses prepared statements, all output is escaped. Identifiers in URLs are constrained and cross-checked against the record's owner.
• Uploads are limited to an allow-list of file types, checked by content rather than by name, capped in size, and refused when they contain executables, scripts or web pages.
• Money is handled in integer minor units with server-side validation; allocations are checked inside a locked transaction, so a partially applied payment cannot exist; approvals are separated from requests.

Audit and monitoring

Sensitive actions — sign-ins and failures, password changes and resets, account changes, permissions, records created, changed or deleted, shared links made and used, releases approved and signed, keys created and rotated — are written to an append-only audit log with the actor, time, address and browser. Every view and download of a shared link is logged. Application errors are recorded with a reference number so we can find them without exposing details to a visitor. Passwords, session identifiers, tokens and file contents never appear in any log.

Software you receive from us

Trust in an update does not rest on the connection alone. Release artifacts are signed with Ed25519 over their SHA-256, and the manifest that offers them is itself signed with an issue and expiry time, so a replayed or tampered update is refused by the client. Software, firmware, licensing and documents each have their own keys; rotation retires a key and revocation publishes it as untrusted. The public keys are served at /api/updates/keys and /api/licensing/keys, and every public download shows its SHA-256 checksum. Licence entitlements and the seals on signed documents are made the same way.

API, connectors and machine credentials

Personal API tokens are shown once, scoped to what their owner may do, optionally read-only, expiring and revocable. Connected applications use OAuth 2.1 with PKCE, single-use codes, rotating refresh tokens and a consent screen that offers only the scopes the user holds. Machines and integrations use service accounts that cannot sign in interactively, so a credential a system carries is never a person's. Every action through a token is audited under the account that authorised it.

Backups and continuity

The database is backed up nightly, with a rolling fourteen days kept and each copy pushed off the host when object storage or the Drive mirror is connected, on top of the backups our hosting provider keeps. Files are versioned and never overwritten, and a scheduled integrity check reads stored files back and compares them with the checksum recorded on upload, reporting anything missing or altered. The restore procedure is written down step by step so that it is rehearsed rather than assumed. The whole codebase is under version control and deployed by a pipeline that refuses to ship when lint or tests fail.

What we do not claim

• We hold no third-party certification such as ISO 27001 or SOC 2, and we have not yet commissioned an independent penetration test. When we do, we will say so here.
• The site and the Hub run on managed shared hosting. We control the application, its configuration and its data; the operating system and network are our provider's.
• Uploaded files are checked by type and content but not scanned for malware. Treat a file another party has shared with you as you would an e-mail attachment.
• Licensing and update signatures protect what a genuine client verifies; software altered to skip verification is outside what a server can enforce.

If something goes wrong

If we learn of a breach that affects information about you or your organisation, we tell the affected account holders by e-mail without undue delay, saying what happened, what information was involved, what we have done and what we suggest you do. Where the law where you are requires a notification to an authority, we make it.

Reporting a weakness

If you have found a vulnerability, please read our responsible disclosure page and tell us. A machine-readable pointer to it lives at /.well-known/security.txt.

Your part

Choose a long password you use nowhere else and switch on two-factor authentication. Keep API tokens and shared links private, revoke what you no longer use, and tell us when someone leaves your organisation. Verify checksums before installing a download, and keep our products updated. Write to us the moment you suspect an account has been misused.