How we work
Security
This page is about the systems we build for clients. Security on this website — what it loads, what it stores, how to report a problem — is on the Trust page. Both exist because a claim you cannot check is not worth making.
Sign-in
Hardware-backed MFA
Audit log
Hash-chained, verifiable
Certification
None held, none claimed
Patient data
Out of scope by design
01
Who can sign in, and how
Access is the control that matters most, because everything else assumes it held.
- Hardware-backed multi-factor authentication using WebAuthn and FIDO2 security keys, so a stolen password is not enough and a phishing page cannot replay a login.
- Roles, not individuals. Permissions attach to a role — administrator, organisation owner, staff — and are enforced on the server, not in the interface.
- Least privilege in the database itself. The credential an application uses to read cannot write, and the credential that writes cannot approve. Separation is enforced where the data lives rather than only in application code.
02
An audit trail that can be checked
Every consequential action is recorded, and the record is hash-chained: each entry carries a hash of the one before it, so a deleted or altered entry breaks the chain and can be detected. Verification is a function anyone with access can run — it is not a report we produce for you.
Audit entries are written by the database as part of the same transaction as the change they describe, which means an action cannot succeed without being logged.
03
Separation between tenants and environments
- Row-level isolation. In multi-tenant systems, one organisation's data is separated from another's by the database's own row-level security, scoped per transaction, rather than by a filter someone might forget to write.
- Separate environments. Development, staging and production are separate infrastructure with separate credentials. A staging credential cannot reach production data.
- Origin lock. Application servers accept traffic only from the edge in front of them, so the origin cannot be reached directly.
04
Where data lives, and what happens to it
- Residency by requirement. Systems built for European clients are hosted in EU regions. Residency is decided before the build.
- Encrypted backups, restore-tested. Backups are encrypted and taken nightly, and a restore is exercised automatically rather than assumed — a backup nobody has restored is a belief, not a backup.
- Secrets in a managed store, never in source control, never in a configuration file committed to a repository.
- No protected health information enters Armage systems by design. See governance.
05
What runs before anything ships
The pipeline is a control, not a convenience. Nothing reaches production without passing it: linting and strict type checking, unit and integration tests, database rule tests, secret scanning, static analysis, dependency vulnerability scanning, and a build that fails on a content-security-policy violation rather than shipping one.
Production deploys are gated and run from the main branch only, with the deployed version verified afterwards rather than assumed.
06
Standards, and what we do not claim
Client systems are engineered against SOC 2 Type II criteria, with a control matrix that maps the security and processing-integrity criteria to specific code and specific tests. Where a regulated domain applies — medical device distribution duties, data protection under the GDPR and Spanish LOPDGDD — the obligations are designed into the workflow rather than added as a policy document.
What we do not claim, stated plainly:
- Armage is not SOC 2 certified. No audit has been purchased or passed.
- Armage holds no ISO certification and no other security attestation.
- No penetration test report exists to share today. When one does, it will be described here with its date and its scope.
A vendor that lists certifications it does not hold fails diligence at the first check. We would rather be shorter and correct.
FAQ
Common questions
- Is Armage SOC 2 certified?
- No. Armage holds no certification and does not claim one. Client systems are engineered against SOC 2 Type II criteria, with a control matrix mapping the security and processing-integrity criteria to specific code and tests. An audit has not been purchased.
- Can we use our own identity provider?
- Yes. Sign-in is built on standard protocols and can be pointed at an institutional identity provider rather than a separate set of credentials.
- Where is data hosted?
- Where the client requires it. Systems built for European clients are hosted in EU regions. Data residency is a configuration decision made before the build, not a migration afterwards.
- How do we report a vulnerability?
- Email security@arm-age.com. The vulnerability disclosure policy sets out scope, safe harbour and a 90-day coordinated disclosure target.
Send us your security questionnaire
We answer them directly rather than returning a brochure. Write to security@arm-age.com, or read the vulnerability disclosure policy and the Trust page.