Careers
We are hiring people who will not ship a biometric gallery before a working revocation path, and who will not treat a legacy cleartext reader as an acceptable fallback.
The work, honestly described.
Most of this is unglamorous systems engineering with real consequences when it is wrong.
Building a converged access control plane means writing software that physically holds doors and refuses to yield a lock screen. A bug is somebody trapped in an anteroom, or a leaver still holding a working badge. That shapes how we work more than any engineering value statement would.
It also means a lot of careful, narrow work: a drop pipeline that provably discards a frame, a state machine with no undefined middle, a compiler that refuses to emit an unsafe policy. If that sounds more interesting than shipping another dashboard, we should talk.
Where we are looking.
These are areas of open interest rather than numbered vacancies. Tell us which one you have actually shipped in.
Inference and portal hardware
Video pipelines, on-device inference, and serial protocols on constrained hardware with a hardware root of trust. Latency budgets measured in tens of milliseconds.
Read moreEndpoint agents
macOS EndpointSecurity clients and Windows credential providers. Small, auditable, no telemetry bloat, and correct across operating system upgrades.
Read moreCompilers and evaluation
Turning declarative rule packs into deterministic artifacts, with floor enforcement, dual control, and evaluation that fails closed.
Read moreCryptography and data protection engineering
Key hierarchies, hardware sealing, provable drop pipelines, and making subject rights resolve mechanically rather than procedurally.
Read moreWorkspace modules
The asset register, service desk, and knowledge product that operations teams open every morning. Depth and correctness over novelty.
Read moreDistributed state
Two-bus revocation topology, epoch fencing, split-brain behaviour, and sites that survive days of isolation.
Read moreHow to apply, and what we will ask.
Applying
We do not run an applicant tracking portal. Use the contact form, select the careers topic, and include a short note on which of the areas above you have genuinely shipped in.
A few paragraphs about a system you built and what went wrong with it is worth considerably more to us than a formatted curriculum vitae.
What we will ask
Expect to discuss a real system you have worked on in depth: what the failure modes were, which ones you did not anticipate, and what you would build differently now.
We do not run timed algorithm puzzles. The work is systems design and careful implementation, so the interview looks like that.
We do not use customer biometric templates to train shared models. That is an architectural constraint rather than a policy we could quietly revisit, and it rules out some product directions. If you would want to argue for reversing it, this is not the right team.
Working here.
Small team
Your work is identifiable, which cuts both ways.
Real deployments
Software that runs in plants and offices, not a pilot that never ships.
Security review
Design review is genuine, and being told no is normal.
Documented architecture
Decisions are written down and reviewed before they are built.
No telemetry products
We are not going to ask you to build surveillance features.
Direct process
A conversation with the people you would work with, not six rounds.
Who to write to.
Tell us what you have actually built.
A paragraph about a system that failed in an interesting way is the best possible opening. Send it on the contact form with the careers topic.