WMS360
A face isn't a password. It can't be reissued.
That single fact shaped how WMS360 was built. Biometric data is the most sensitive thing this system holds, and everything below follows from taking that seriously rather than treating a face template as one more column.
Encrypted, unlogged, unexportable, erasable.
A password breach is a bad week. A biometric breach is permanent — the affected person cannot be issued a new face. WMS360 therefore treats face data as something to be minimised, protected and, on request, destroyed.
- Encrypted at rest. Face data is encrypted in the database, not stored as retrievable plaintext.
- Never written to a log. Biometric values are excluded from diagnostic output, so they can't leak through a log aggregator that has looser access rules than the database.
- Never returned raw over the API. Verification returns a verdict. It does not hand back the template that produced it.
- Right to erasure. A dedicated permission permanently erases an employee's profile, including cleaning up identities orphaned at the recognition provider — so "delete my data" doesn't leave a copy behind at a third party.
- Enrollment requires approval. A face profile is not trusted until an administrator reviews and approves it.
- Provider is pluggable. The recognition engine sits behind an interface, so it can be changed — including to one that runs inside your own perimeter — without re-architecting the product.
Access is composed, never assumed.
The most common failure in workforce systems isn't a breach — it's a supervisor who can see, and change, an entire organization's records because the role model only had three tiers.
Token-based authentication
JWT bearer authentication, with policy-based authorization evaluated per action rather than per screen. Hiding a button is not access control; WMS360 enforces the permission at the API.
Around 65 granular permissions
Rights are individually held in the shape Area.Entity.Verb. Approving an attendance correction, reopening a locked payroll period and erasing a biometric profile are three separate permissions, and almost nobody should hold the third.
Data scoping
A user's scope — zone, ward, office — is assigned explicitly. A supervisor sees their own people and nobody else's, regardless of what their job title suggests they ought to see.
Custom roles
Roles are yours to define and are compositions of permissions, so your access model can match your actual organization instead of bending to fit four fixed tiers.
A stolen database shouldn't become a stolen workforce.
Everything that could be replayed is stored as a hash, so possession of the database does not confer the ability to authenticate as anyone.
- Argon2id password hashing — the algorithm OWASP recommends for new systems, chosen for its resistance to GPU-accelerated cracking.
- Refresh tokens are stored as hashes only. The raw token exists in transit and in the client, never at rest on our side.
- One-time passwords are stored as hashes only, for the same reason.
- Non-enumerable public identifiers. Every externally addressable record is referenced by an unguessable identifier rather than a sequential number, so nobody walks your entire employee list by counting upward from one.
Privileged actions leave a trace by default.
Immutable audit log
Who approved what, who reopened a locked period, who erased which biometric profile, and when. Recorded as the action happens, not reconstructed later from database diffs.
Three-tier soft delete
Records retire rather than disappear, so last year's attendance report still tells the truth about last year — while a genuine erasure request is still honoured completely.
Environment separation
QA and production are distinct environments with isolated credentials. Production secrets are not reachable from a test deployment.
Where the data lives is your decision.
Biometric data is regulated differently in different jurisdictions, and some organizations are contractually prohibited from putting it in a public cloud at all. WMS360 runs in cloud, in a private cloud tenancy of your choosing, or fully on-premise inside your perimeter — with local-disk storage for face images and documents so an on-premise install has no external storage dependency.
See deployment optionsThe detail a security review actually needs
This page states the model. For the detail a review needs — dependency and patch policy, backup and disaster recovery, sub-processors, incident response and environment separation — talk to us and we'll answer your team directly.
We deliberately don't publish component versions, cryptographic parameters or infrastructure specifics on a public page — that information is reconnaissance for an attacker and gives a genuine reviewer nothing they can't get from us directly.
Bring your security team to the demo.
The questions they'll ask are the ones this product was designed around. We'd rather answer them in week one than in procurement.