​Autonomous penetration testing that reports only what an attacker could actually exploit.

​

Real offensive tradecraft running as a service, without a red team on payroll. No scanner noise. No thousand line reports of theoretical findings. Just the handful of things that would get you breached, each one proven by exploitation.

​

Access starts with a short call, because we verify who you are and what you own before we hand over a tool that runs real attacks.

​

Schedule a call

​

Scanners bury you in findings that do not matter

Traditional vulnerability assessment flags everything it can see and inflates the severity of most of it. Unreachable services, unauthenticated banners, false positives your team spends weeks triaging. You end up staring at a spreadsheet of five hundred items while the two paths that actually lead to domain admin sit quietly in the middle of it.

​

A CVSS score is not an attack. A flagged version string is not a breach. You do not need a longer list. You need to know what an adversary would do with what you have.

​

Severity is not exploitability

A scanner finds Apache running a version with a critical rating. There is no public exploit code, the vulnerable module is not loaded, and nothing reachable touches the affected function. It sits at the top of your report for six months because the number is high.

​

Meanwhile the application your own team built takes an unsanitized parameter and hands back the customer table. There is no CVE for it. It has no severity score. Nothing in the scanner's database describes it, so it never appears on the report at all.

​

One of those is a number. The other is a breach.

​

Nobody catalogued the code you wrote

Every CVE-based tool can only tell you about software somebody else published and somebody else catalogued. That is most of a scanner's value and all of its ceiling. The applications your developers built, the integrations glued together over a decade, the internal portal nobody has touched since the person who wrote it left, none of that exists in any vulnerability database.

​

Which is exactly where an attacker goes. He is not hunting for the CVE you already know about. He is looking for the thing you built yourself, because nobody has ever tested it and nobody is going to publish a patch for it.

​

Latchkey attacks what is in front of it rather than matching what it sees against a list. If a parameter takes injection, it proves it by pulling data back. If a credential works somewhere it should not, it proves it by using it.

​

Attackers do not take vulnerabilities one at a time

The finding that ends up in a breach report is rarely the one that scored highest. It is usually three things that each looked survivable on their own. A medium severity issue on a host nobody considered sensitive, a service account with more rights than anyone remembered granting, and a trust relationship between two systems that made sense when it was built.

​

Ranked individually, none of those get fixed this quarter. Chained together they reach the data. That gap between a list of vulnerabilities and your real exposure is the entire reason exposure management is displacing vulnerability management, and it is the gap Latchkey is built to close.

​

Latchkey runs the chain. It does not report the first link and leave you to imagine the rest. It follows the path as far as the path goes and tells you where it ended up.

​

It runs the attack, not the checklist

Latchkey chains offensive techniques the way an operator would. Network discovery, service enumeration, credential attacks, exploitation, and post exploitation, orchestrated end to end and unattended. Nobody babysits a console. Nobody stitches tools together.

​

We build Latchkey out of the work we do on live red team engagements. When we find something that works in the field, it goes into the product.

​

That is where the technique library comes from and that is what separates it from a scanner with a marketing budget.

​

If it cannot be exploited, it does not get reported

Every finding is validated by exploiting it, not inferred from a version number. You get a short, ranked list of proven attack paths. Each one comes with the evidence, the real world impact, and the fix.

​

The Apache finding with no reachable exploit path does not make the report. The injection flaw in your own application, with the query that worked and the records it returned, does.

​

No theoretical maybes. No padding to make the report look thorough. If an attacker could not use it, it does not make the report.

​

We verify before we hand over the keys

Latchkey runs real attacks against real systems. Anyone willing to sell that to a stranger with a credit card and no questions asked is not somebody you should be buying offensive tooling from.

​

So access starts with a conversation. We confirm who you are, we confirm the assets you want tested actually belong to you or that you hold written permission to test them, and we get authorization documented before anything runs. It takes one short call.

​

That call is also where we tell you honestly whether Latchkey fits your environment. Sometimes the answer is that what you need is a human engagement instead, and we would rather say so upfront than take a subscription that was never going to help you.

​

Schedule a call

​

How it works

Get verified. A short call to confirm identity, ownership of the assets in scope, and written authorization. This happens once.

​

Deploy the appliance. A virtual appliance drops into your network on your hypervisor. VMware, Hyper-V, Proxmox, KVM, or a cloud image. It runs on your hardware, which is why internal testing costs what it costs.

​

Run it. Discovery, enumeration, exploitation, and pivoting run in sequence without supervision, against the ranges on your scope manifest. Every action is logged.

​

Read the results on your own network. The appliance serves its own portal. Findings, evidence, and reports live on the appliance and stay inside your environment.

​

Scope is enforced, not configured

The appliance ships sealed. There is no shell, no console, and no configuration file you can edit, because a scope restriction the customer can turn off is not a restriction.

​

Your authorized ranges are issued as a signed manifest tied to your license and matched against the authorization you provided during onboarding. Any target outside that manifest is rejected before a packet leaves the appliance. If you want the scope changed, that goes through us.

​

We built it this way on purpose. A tool that runs real attacks should not be able to point itself at somebody else's network because a configuration field was easy to reach.

​

Your findings never leave your network

The appliance runs its own portal. You log in on your LAN, read the proven attack paths, pull the evidence, and export whatever you need. All of it stays on the appliance.

​

We do not store your findings, your topology, or your attack paths, because we do not want a copy of the fastest way into your environment sitting on our infrastructure any more than you want it there. The appliance reports its license status and scope validation back to us. It never reports what it found.

​

We test the thing we are asking you to install

You are putting a sealed box on your network and you cannot look inside it. That is a fair thing to be uncomfortable about, so here is what we do about it.

​

The appliance codebase is scanned nightly for application level flaws and dependency vulnerabilities, and findings get fixed before they ship rather than tracked in a backlog. On top of that we test the appliance manually the same way we test our clients, because a scanner finds what it has a signature for and we would rather find the rest ourselves than have you find it.

​

We build offensive tooling. We know exactly what a well placed appliance is worth to an attacker, which is why we treat this one as a target.

​

What it costs

Founding member pricing. Twenty dollars a month, locked permanently, for the first fifty accounts. That price does not expire and it does not step up at renewal. When the fifty are gone it closes.

​

The founding tier covers unlimited testing inside your own environment. The appliance runs on your hardware against the ranges you declared and we verified, so there is no per scan fee, no seat math, and no run limit. Run it nightly, run it after every deploy, run it before the board meeting.

​

Public internet and cloud hosted assets are scoped and quoted separately. Anything reachable from outside your network is tested from our infrastructure, and only after we have confirmed the assets belong to you. That takes a short call to verify ownership, size the environment, and price it.

​

External scope is where authorization actually matters. Attacking something the whole internet can reach is not a place we are willing to take anyone's word for it, and it is not something we can price sight unseen.

​

Schedule a call

​

Who it is for​

• Teams without a full time offensive capability who still need to know their real exposure.

• Engineers who refuse to wait for the annual pentest to find out an attacker already had a way in.

• Security leaders stuck between a quarterly scan that finds nothing useful and an annual engagement that finds everything eleven months too late.

 

Where Latchkey stops​

Latchkey finds the technical paths an adversary would take through your infrastructure. It does not walk into your lobby, it does not call your help desk, and it does not tell you what a determined human does with a work order and a high visibility vest.

​

Automated testing tells you what is reachable. It cannot tell you what happens when someone decides to try. When you need that answer, Penetration Testing or Active Threat Emulation Testing are where the people come in.

​

Built for authorized testing​

Latchkey is for systems you own or are explicitly authorized to assess. Ownership and authorization are verified before your appliance is licensed, scope is enforced by signed manifest rather than configuration, and every action is logged.

​

Exploitation is real, which means it can cause state change on live systems. Run it against production the way you would run any authorized test, with a window and a rollback plan if the environment is fragile.

​

We build offensive tooling for defenders. Responsible use is part of the product, not an afterthought.

​

Stop reading reports nobody acts on​

See the attacks that matter, proven and ranked, in plain language. Start with a short call so we can get you verified and running.

​

Schedule a call

​

Common questions

• Why can I not just sign up? Because Latchkey runs real attacks. We verify identity and asset ownership before licensing an appliance, and we get authorization documented. It is one short call and it happens once.

• How long does verification take? One call, plus the time it takes you to confirm the assets in scope are yours. Most accounts are provisioned the same week.

• How is it deployed? A virtual appliance runs on your hypervisor inside your network. VMware, Hyper-V, Proxmox, KVM, or a cloud image.

• Why can I not log into the appliance? You log into the portal it serves. What you cannot reach is the operating system underneath, because scope enforcement has to live somewhere the customer cannot turn it off. That is what makes unlimited internal testing something we can actually offer.

• Where do my findings live? On the appliance, inside your network. We do not store your results. The appliance sends license and scope validation back to us and nothing else.

• How do I know the appliance is not a risk on my network? We scan the codebase nightly for application and dependency flaws, and we test the appliance by hand the way we test client systems. It is the same threat model we would apply to any vendor box we found during an engagement, applied to our own.

• What if I need to change my scope? Send us the new ranges with the same ownership verification we did at onboarding. New manifest, usually same day. Adding public internet or cloud hosted assets takes a short scoping call.

• Why do external assets need a scoping call? Two reasons and both are honest. Testing something reachable from the public internet means launching attacks at a target anyone can see, so ownership gets verified rather than asserted. And external testing runs on our infrastructure, so cost scales with your scope and cannot be flat priced without one of us getting a bad deal.

• Is this a vulnerability scanner? No. A scanner lists what might be wrong. Latchkey proves what an attacker can actually do.

• My scanner already gives me severity scores. Why is that not enough? Because severity describes a finding and exploitability describes your risk. A critical rating on something unreachable is noise. A flaw in an application you built yourself has no rating at all and never shows up on a scanner report, and that is frequently the one that matters.

• How is this different from the enterprise validation platforms? Two things. Price, because those platforms are six figure purchases that move through procurement for a quarter before anyone runs a test. And provenance, because we still run human red team engagements and everything we learn in the field feeds the product.

• Do I need offensive security skills to use it? No. It runs on its own and reports in language you can act on without a red team to interpret it.

• What do I have to authorize? Only assets you own or have written permission to test. Ownership is verified during onboarding and enforced by the scope manifest.

• Can I test a client's environment? Yes, with their written authorization on file. Bring it to the verification call and we will issue a manifest scoped to that client.

• How often can I run it? Inside your own environment, as often as you want. There is no run limit on internal testing. Public and cloud hosted assets run from our infrastructure against a scope we verified together, so frequency there is whatever we agree on the scoping call.

• Will it break something? Exploitation is real, so it can cause state change. Treat a run the way you would treat any other authorized test against production.

• What do I get at the end? A ranked list of proven attack paths, each one with exploitation evidence, business impact, and remediation guidance.

• Does this replace a red team engagement? No. Latchkey covers the technical attack surface. It does not cover people, buildings, or the pretext that gets someone through a door. Those stay with our assessment team.

​