Field notes on building trustworthy systems
Writing from our practices on the decisions that make public-sector technology secure, private, and durable, drawn from the systems we actually build.
Signing a credential you can hand to a stranger
A confirmation code is going to be screenshotted, forwarded, and read aloud over the phone. You cannot keep it secret. What you can do is make it impossible to forge and trivial to verify.
A border form that fits on one screen
The person filling in a government form is often tired, on a phone, on airport wifi, with a queue behind them. The interface is not where you express creativity. It is where you remove every reason to fail.
No account, no password: recalling a record without a login
The most secure credential is often the one you never issued. For a system used once or twice a year, an account is a liability. Here is how we let a traveler retrieve their submission without one.
Accessibility is a release gate, not a finishing touch
For a system a citizen cannot opt out of, an inaccessible screen is a failure of delivery, not a missing nicety. We treat WCAG conformance the way we treat a failing test: it blocks the merge.
The audit log that cannot be quietly edited
Who read this record, who changed it, and when. A system that holds sensitive data has to answer that honestly, which means the people with the most access need the least ability to rewrite the answer.
The system advises, the officer decides
Software can sort, surface, and flag faster than any person. What it should not do is make the final call on a human being. Keeping a trained official in the decision is both an ethical line and an engineering one.
Giving the browser less to give away
Security-relevant logic never ships to the client, but the client is still worth hardening. Stripping a production build and locking down the page does not keep secrets. It raises the cost of every other attack.
Biometrics you are relieved to have deleted
A face or a fingerprint is the one credential a person can never reissue. The responsible way to handle it is to hold it for the shortest possible moment, never in its raw form, and to make deletion automatic.
Where secrets live, and where they never do
A credential committed to a repository is a credential you have to assume is public. Keeping secrets out of the codebase, and out of human hands, is a design decision made once and enforced everywhere.
The client is always untrusted: designing systems that assume compromise
A customer's browser, a partner's API call, and a shared terminal are all attacker-reachable. The discipline that keeps a critical system safe is deciding what is allowed to run there, and what never can.
Data minimization as law, not policy
The safest data is the data you never collected. We treat minimization as a hard constraint on the schema, not a value statement in a policy document.
Replacing a critical legacy system without taking it offline
Modernization fails when it treats the old system as something to switch off on a Friday. The real constraint is that the service it runs cannot stop.
What a credible security audit actually covers
A scan is not an audit, and a clean report is not a safe system. Here is what separates an assessment a regulator can rely on from a PDF that just looks reassuring.
One accessible codebase for the phone, the desktop, and the on-site terminal
Three devices, three contexts, one application. Building adaptively rather than separately is what keeps accessibility a guarantee instead of a per-platform afterthought.
Relocatable by design: avoiding cloud lock-in in public infrastructure
A government system can be hosted on a commercial cloud today and still be free to move tomorrow. The trick is to decide that on day one, in code.
Have a system you want a second opinion on?
We are happy to talk through an architecture, a program, or an assessment, whether or not it turns into an engagement.