For B2B and B2C software companies, developer and data platforms, and managed service providers
In a multi-tenant product one missing check can expose every customer at once, and the customer who finds it may be the one running your security review. We test the boundaries that keep tenants apart: authorisation on every object, single sign-on and SCIM provisioning, API keys and integrations, the cloud account underneath, and the pipeline that deploys to it.
An attacker who breaks tenant isolation gets every customer's data rather than one, and an attacker who reaches your cloud control plane or your build pipeline can ship code into every customer environment you touch. Enterprise procurement asks for a security questionnaire, a recent penetration test and an attestation letter, and a single cross-tenant finding in a prospect's own testing can stall the deal until you can show the fix and a retest.
Identifiers in URLs, GraphQL queries and export jobs are checked for a valid session but not for tenant ownership. The flaw tends to hide in features added after the core access model was designed: reports, exports, file previews and webhooks.
OAuth grants, personal access tokens and API keys issued to integrations outlive the people who created them and are rarely scoped tightly. When an integration provider is breached, attackers replay its tokens against every platform it connects to, and a supplier's incident becomes yours.
Passwords stolen by infostealer malware are tried against customer logins, admin consoles and data platforms. Accounts where multi-factor authentication is optional, especially service and support accounts, are where these campaigns succeed.
Cloud keys committed to repositories, baked into container layers or printed in CI logs are harvested by automated scanners soon after they appear. One leaked deployment key can be worth more to an attacker than any application bug.
A malicious package, a poisoned CI action or an over-privileged build runner gives an attacker the right to build and deploy your product.
Features that fetch a URL on the user's behalf (link previews, webhooks, PDF renderers, importers) can be pointed at internal services and at the instance metadata endpoint, which hands out the workload's cloud credentials.
SOC 2 does not require a penetration test by name, but its monitoring criteria list penetration testing among the separate evaluations an organisation can use, and auditors often ask for one covering the systems inside the report boundary. ISO/IEC 27001:2022 is similar: controls 8.8 and 8.29 cover technical vulnerability management and security testing in development and acceptance without prescribing a test, and the transition from the 2013 edition ended on 31 October 2025. Cloud computing providers and managed service providers are in NIS2's sectors of high criticality. Installable software, agents and SDKs you place on the EU market are products under the Cyber Resilience Act, whose reporting obligations have applied since 11 September 2026 and whose main obligations apply from 11 December 2027. US domestic registrants disclose a material cybersecurity incident on Form 8-K, generally within four business days of determining that it is material; foreign private issuers furnish on Form 6-K what they disclose about such incidents elsewhere.
The scoping call settles which of these apply to your systems.
Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.
Duration: 5 to 10 working days
An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.
Duration: 4 to 8 working days
A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.
Duration: 5 to 15 working days, depending on codebase size
Adversarial testing of features built on large language models: chat assistants, retrieval-augmented search, agents with tool access, and generated output that reaches users or other systems. We test whether the model can be steered into leaking data, taking actions it should not, or passing untrusted output into the rest of your stack.
Duration: 4 to 10 working days
Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.
Duration: 2 to 5 days per system, remote or on site
Closest written-up engagement
Logistics SaaS · About a month
The trust team was seeing partner logins with privileges nobody had granted.
Scoping calls are usually available within two working days, and most engagements start within two weeks of a signed scope. A typical web application test runs 5 to 10 working days, followed by 2 to 3 days of reporting. If a deal is blocked, say so on the call and we will give you the earliest date we can start.
If you can. With source access a tester reads how an authorisation check is meant to work instead of inferring it, which finds tenancy flaws faster and with fewer false leads. Teams that want depth across the whole codebase book an application security audit; teams that need an outside-in view for a customer keep the test black-box and share code only where a finding needs confirming.
Only if it is in scope, and it usually should be. An application test shows what a user can reach; a cloud configuration review shows what a compromised workload or a leaked key can reach. Many of the findings that matter sit where the two meet, such as an SSRF that hands out a role with read access to every tenant's storage.
The target changes: your access is what an attacker wants. We test the tools that give you standing access to customers (remote management, ticketing and backup consoles, shared admin accounts) and how far one compromised technician account reaches. NIS2 places managed service providers among its sectors of high criticality, and customers within its scope have their own reasons to ask how that access is controlled.
We pick the checks that apply to your systems and the frameworks you answer to. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.