You own security engineering for a pharmacy robot and everything it talks to: the machine, its operating-system image, the software that runs on it, the cloud service that commands it, and the path that updates it. When a customer asks how each machine proves its identity, who can reach it and how, and what an independent test found and what was done about it, the answer rests on your work, and every statement in it is backed by something the system produces.
🏢 About Queue Inc
Queue builds robots to fill prescriptions. Our machine is designed to take stock bottles of medication and produce counted, labeled vials, so that pharmacists and technicians can spend their time on patients. Our first product is built to work behind the pharmacy counter and to be operated by pharmacy staff.
🎯 The Role
You own security engineering for a pharmacy robot and everything it talks to: the machine, its operating-system image, the software that runs on it, the cloud service that commands it, and the path that updates it. When a customer asks how each machine proves its identity, who can reach it and how, and what an independent test found and what was done about it, the answer rests on your work, and every statement in it is backed by something the system produces.
✅ Key Responsibilities
The threat model — A written model of the trust boundaries: machine to cloud, operator to screen, the update path, remote support, and suppliers. You keep it current as designs change.
Security review of designs — Designs come to you early; you review them and your review is recorded.
Device identity and key custody — The threat model, the priorities and the verification are yours. The engineers who own the operating-system image build the platform side with you.
Independent security testing — Scope, test environment, triage, remediation with the owning squads, and retest evidence. You run it end to end.
Finding and fixing weaknesses — How weaknesses in our code, dependencies, device images and cloud are found, triaged and fixed. It is shared with the squads that own each part: you set the rules, track each finding to closure and report where we stand.
Incident response — The security side of every incident: detection, triage, containment, evidence and what changes afterwards. It is shared with the owning squads, and you run it with the systems reliability engineers, who run the operational response.
Customer security reviews — A customer's security review asks detailed questions and treats our answers as commitments. Before a statement is sent, you check it against the evidence that can substantiate it: the versioned implementation, the deployed configuration and the operational records. A statement says what is built, what is designed and what is planned, and keeps the three apart.
Cloud posture — Identity and access, secrets, the review of infrastructure changes, and what the cloud provider's detection services report.
Security and privacy controls — For the controls Queue commits to, including those that follow from HIPAA, you verify each control in the system and take its evidence from the system.
You assess and you recommend. You do not accept risk on the company's behalf: an exception is recorded with its approver and conditions, and an authorized business owner accepts what remains.
📌 Required Qualifications
Ownership — you have owned the security of a shipped product end to end, and you can describe a problem you found, fixed and followed until it stayed fixed. Consulting alone or compliance alone is not this.
You build — you read and write code. Ours is Rust, TypeScript and Python: deep skill in one and comfort reading the others. Your reviews come with a patch or with guidance precise enough to act on.
Systems and network depth — TLS and certificates, identity and access, secrets management, Linux hardening. You can reason about a trust boundary from the hardware to the cloud.
Offensive fluency with defensive judgment — you have run or worked closely with penetration tests. You rank issues by what they could do to this system and its users, and you can defend deferring one.
Threat modeling that engineers use — you would sooner remove an input than add a control, and engineers ask for your review.
Exact writing — you state what is true at the strength the evidence supports, to an engineer, an executive or a customer's assessor.
⭐ Desirable Experience
Device security: verified start-up, hardware-held keys, signed updates, fleet identity.
Security in healthcare or another regulated industry, and customer security reviews from the supplier's side.
Working knowledge of IEC 62443, UL 2900-1 or NISTIR 8259.
🎁 Benefits
Ownership — security engineering for the machine and everything it talks to Hard problems: trust boundaries from the hardware to the cloud, device identity and key custody, and the path that updates the machine Small team, zero bureaucracy, high trust
🛂 Visa & Eligibility
Why Join Us Now? Impact & Growth Direct Impact: You check every security statement against the evidence behind it before it goes to a customer Growth: The w
Please let Queueinc know that you found this role at devopsprojectshq.com as a way to support us, so we can keep providing you with awesome DevOps jobs.
Never miss a job
Join 2,000+ DevOps developers getting weekly alerts for remote and US/EU roles, Kubernetes, AWS, Terraform, filtered for your stack.
🔒 Need an IP to whitelist?
Get a dedicated static EU outbound IP for Banks, payments, EHRs, APIs, AI.