External penetration testing from the adversary's perspective. No internal access, no assumptions — we map real attack paths and hand your team a fix-ready report.
External assets, applications, APIs, and open-source intelligence — everything an adversary could reach and exploit without ever touching an internal network. This mirrors the real threat model most organizations actually face: attackers don't start with a VPN credential.
Destructive testing, denial-of-service conditions, and social engineering are out of scope by default. We'll tell you directly if we think adding them serves your goals — this isn't a limitation we hide, it's a scope decision made with you upfront.
No internal access, no assumed foothold. We start where a real adversary starts — public information, exposed services, and application logic — and follow the same path an attacker would follow. This is a genuine constraint on the engagement, not a marketing claim: it's what makes the findings representative of real risk instead of theoretical risk.
Testing of your externally-facing assets — applications, websites, APIs, and infrastructure reachable from the public internet — using the same reconnaissance and exploitation approach a real attacker would use.
Yes — this is the default model. We work from public/adversary-visible information and no internal access, so the test reflects what an outside attacker actually faces, not what a credentialed scan reports.
Exploitation is controlled and scoped to avoid service disruption. Anything with real availability risk is flagged and coordinated with you before it runs, not attempted opportunistically.
Destructive testing, denial-of-service, and social engineering are out of scope by default — they can be added only with explicit written authorization, and we'll tell you plainly if we think that's a bad idea for your situation.
Typically measured in weeks, scaling with the size of the external attack surface. You get a specific timeline once scope is defined, not a generic range.
The report includes production-ready fix instructions for every finding — not just a vulnerability list. If you want ACS engineers implementing fixes directly, that pairs with our Vulnerability Remediation service.
Yes, retesting against the original findings is available to confirm the fix actually closes the issue rather than just changing its symptoms.
Yes, standard practice for this work.
Tell us what's externally exposed. We'll scope a realistic engagement and timeline — no generic proposal.