Need deeper validation? Explore consent-gated Active Pentest
BreakMesh shield BreakMesh – Vulnerability Simulator & Cyber Range

Security & Trust

How we handle the trust you're putting in us

Running BreakMesh means holding your scan findings, read-only cloud credentials, and — if you use Mobile Security — your uploaded app binaries, alongside every other customer's. We think a platform that finds security gaps for a living owes you a plain answer to "what about your own security?" — including the parts that are still in progress.

How we protect the platform itself

  • Password & credential storage. User passwords are hashed with Argon2id, not a reversible or fast-hash scheme.
  • Admin access. Multi-factor authentication is required for administrative accounts.
  • Outbound scanning traffic. Scanner requests run through SSRF-protected outbound paths, so a scan can't be used to reach internal infrastructure that isn't the intended target.
  • Data isolation. Customer data is separated by organization at the data-access layer — one customer's findings, targets, and cloud credentials are not reachable from another's account.
  • Our own domain. breakmesh.io runs the same security-header baseline our Basic Hygiene package checks for on your sites.
  • Cloud Posture credentials. AWS/Azure/GCP credentials you connect for Cloud Posture scanning are read-only by design and are never persisted in scan evidence or reports.

How Active Pentest is governed

Active Pentest runs real exploitation attempts, not indicators — so it's the one part of BreakMesh with genuine potential to affect a live system, and we treat it accordingly.

  • Signed Rules of Engagement, enforced in code. An engagement cannot leave its "awaiting consent" state without the customer submitting a hash that matches our current Rules of Engagement document, plus five separate acknowledgements covering scope, permitted techniques, liability, time bounds, and data retention. This isn't a checkbox on a form — it's a hard gate in the engagement service layer that a scan cannot bypass.
  • Time-bounded, every time. Every engagement is strictly bounded to an approved scope and a fixed testing window from the moment of consent. Continuing past that window requires new consent, not an extension.
  • Destructive techniques are disabled at the platform level. Permitted active techniques are read-only SQL probes, canary XSS injection, path-traversal reads, authentication bypass checks, timing-based injection detection, and callback-confirmed SSRF/XXE. Destructive actions — data deletion, file writes, reverse shells — are never used and are not present in the platform's capabilities, not merely excluded by policy.
  • Usage-capped by plan, not open-ended. Pentest engagements are capped per billing period by plan tier (see pricing) — predictable for budgeting, and a natural ceiling on how much active testing traffic any customer generates.
  • Emergency pause. If a check identifies something that could cause immediate harm, the engagement pauses automatically and the customer is notified before anything continues.

Where we're honest about not being finished

We'd rather say this plainly than leave it unaddressed. BreakMesh is not yet SOC 2 or ISO 27001 certified for its own operations. What's true today is the internal practices listed above; a formal third-party attestation of BreakMesh's own infrastructure is on our roadmap, not yet complete. If a compliance attestation of BreakMesh itself is a requirement for your evaluation, contact us and we'll tell you where things stand.

Related pages