Fixed-scope engagement
Secure Access Build
The old idea of "inside the office network = trusted" stopped working when work went remote. We rebuild access around who someone is and what device they're using — so one stolen laptop or leaked password no longer opens everything you have.
A Secure Access Build moves your access model from "trusted because you're on the network" to "trusted because of verified identity and device posture" — zero-trust access and segmentation enforced through policy-as-code you own, not a perimeter you hope holds.
Start a conversationThe problem zero-trust access solves
"Our security still basically means VPN-in-and-you're-trusted. Remote work, contractors, and SaaS broke that model years ago, and we know one stolen laptop or credential gives an attacker lateral access far beyond what that identity should ever need. Vendors keep pitching us a zero-trust product; we need the actual architecture and enforcement, not a logo." Root cause: implicit network trust + flat internal access means a single compromised identity or device has lateral reach far beyond its need; ZTNA products without an access-policy model just relocate the problem.
What you own when we leave
- An access-policy model expressed as policy-as-code (identity + device posture + resource sensitivity → allow/deny), in your repo.
- Terraform/IaC for the enforcement points in scope (identity-aware access, segmentation, conditional access, service-to-service auth).
- A threat model showing lateral-movement paths before and after, so the risk reduction is legible and reviewable.
- Phased rollout runbooks (so you cut over without locking your own people out) and break-glass procedures.
- ADRs for the trust-boundary and enforcement decisions.
Not a maturity-model spreadsheet. A working enforcement model defined as code.
How we approach it
- 01
Discovery
We read your accounts, configs, and constraints directly (scoped read-only access or exported state), map the real current state, and agree on a written scope and success criteria before any code is written.
- 02
Architecture Decision Records
We write down the key decisions — what we’re doing, the options we rejected, and why — as ADRs in your repo, so the reasoning survives long after we’re gone and you can challenge it before we build.
- 03
Implementation
We build the solution as reviewable Terraform/IaC in small, tested pull requests against your CI, so you watch it land incrementally and nothing arrives as a black box.
- 04
Handover
We walk your team through the repo, the threat model, and the runbooks live, confirm you can apply/destroy/extend it yourselves, and then we leave. You own everything — there is no phase 5 where you still need us.
Engagement shape
A fixed-scope build over a defined set of users, applications, and access paths — phased so each cutover is reversible and observed. Scope is bounded by which access paths and enforcement points are in the first phase, agreed up front.
Fixed price, agreed in writing before we start. You can stop at the decision point and keep everything produced.
- 90-day warranty: anything we shipped that does not behave as documented, we fix at no charge.
- Discovery runs on read-only roles you create and can revoke at any second — we complete your security questionnaire before you grant anything.
- Want us on call afterward? An optional prepaid support block keeps senior hours available for anything that comes up — never a required retainer.
A sample of what we ship
# policy/access.rego — identity + device posture + sensitivity
package access
default allow := false
allow if {
input.user.mfa_verified
input.device.managed
input.device.disk_encrypted
resource_tier_permitted
}
resource_tier_permitted if {
input.resource.tier != "restricted"
}
resource_tier_permitted if {
input.resource.tier == "restricted"
input.user.group in data.restricted_access_groups
input.device.posture_checked_within_hours <= 24
}FAQ
Questions about this engagement
What do I actually get — is this just a report?
No. Every engagement ends with infrastructure-as-code in your repository: Terraform/IaC, the guardrail set (Service Control Policies or equivalents), a threat model, ADRs, and runbooks. The documents exist to help an engineer run the code — they are never the deliverable instead of the code. "We ship, not slide" is the whole point. The sample Terraform on this site shows the shape of what you get.
What if something breaks after you’ve handed over and left?
Every engagement includes a 90-day warranty: if anything we shipped does not behave as documented, we fix it at no charge — that is a defect we own, not new scope. After that window the code is standard Terraform/IaC on standard tools, so your team or any engineer can maintain it. If you would rather we come back for a defined follow-on — a new scope, a new fixed price — we are a short email away. We make ourselves unnecessary by default; we do not make ourselves unreachable.
Can we keep you around after the engagement?
Yes, two ways — both optional, and neither is a retainer you are locked into. A support block: a prepaid block of senior hours your team draws on for anything that comes up — fixes beyond the 90-day warranty, changes, questions, small new pieces of work — scoped and priced in writing like everything else. And hands-on training: sessions that teach your team the systems we shipped, or anything else we know, built on your real environment rather than generic courseware. Neither is required; the handover exists so you can run everything without us.
We already have a security team / platform team. Why bring you in?
Usually because they are at capacity, or the work needs a specific senior depth (landing-zone design, zero-trust enforcement, hybrid routing, AI guardrails) that is hard to staff for a one-time build. We work as reviewable PRs against your CI so your team reviews and absorbs everything as it lands — by handover it is genuinely theirs, not a black box dropped on them.
What access do you need, and how do you handle our data and credentials?
Discovery uses scoped, read-only IAM roles that you create in your accounts and can revoke at any second — never long-lived keys we hold. Where you must export configuration or state, it lands encrypted in storage you control, and we delete our working copies on a documented schedule with written confirmation. We use no sub-processors and nothing leaves the jurisdiction you specify; wherever possible, implementation runs entirely inside your own tenancy and CI so we never hold your credentials at all. We will complete your security questionnaire (CAIQ/SIG-lite) before you grant any access. You can inspect this site too: cookie-free self-hosted analytics, Cloudflare only for edge/CDN and bot protection, a clean CSP, and no third-party trackers.