Find the path to your data before an attacker does.
Authorized penetration testing and security assessment for cloud and device platforms: we show which weaknesses combine into a real route to your data, then retest to confirm each fix closes it.
Much of the attack surface is identity and configuration.
Cloud penetration testing is only partly about servers. The worst findings are usually chains: a small bug, a permissive role and a reachable metadata service adding up to administrative access. A scanner lists each piece; we test whether they connect.
External testing
Starts with no credentials, the way an outside attacker would: public endpoints, exposed services, leaked secrets.
Assumed-breach testing
Starts with a low-privilege foothold, such as a developer credential, a compromised container or one API key, and measures the blast radius.
Configuration review
Accounts, networks, IAM and storage audited against good practice, so the manual testing spends its time on what matters.
The cloud attack surface.
Identity and access management
Roles, policies and trust relationships: wildcard permissions, unexpected assume-role paths, cross-account trust that is broader than intended, and privilege-escalation chains that look harmless one permission at a time.
Metadata service and SSRF
Whether a server-side request forgery bug can reach the instance metadata endpoint and read role credentials, whether session tokens are enforced (IMDSv2 on AWS), and whether the attached role is scoped to the workload.
Storage, secrets and exposed services
Publicly readable or writable storage, over-shared snapshots, management ports and dashboards open to the internet, and secrets in repositories, images, build logs and history.
APIs and application logic
The OWASP API Security Top 10, with emphasis on broken object-level and function-level authorization, tested by acting as two different users or tenants.
Containers and Kubernetes
Privileged containers, over-broad service-account tokens and RBAC, exposed kubelet or dashboard endpoints, missing network policies, benchmarked against CIS guidance and then exercised.
Serverless and event-driven code
Event injection through queues, storage notifications and HTTP triggers, shared over-broad execution roles, and secrets passed as plain environment variables.
Multi-tenant isolation
Tenant separation at every layer it is enforced: API authorization, database rows or schemas, storage prefixes, cache keys, job queues and logs.
CI/CD pipeline
Who can change pipeline definitions, whether untrusted pull-request builds can reach secrets, how runners get cloud credentials, and whether artifacts are verified before deploy.
From scoping to retest.
The goal is not a long list of findings. It is to show which weaknesses combine into a real path to your data, and to prove the fixes work.
Scoping
Assets, rules of engagement, success criteria
Threat model
Crown jewels, actors, trust boundaries
Recon
External surface and configuration review
Initial access
API, web, exposed service or leaked credential
Escalation
IAM, metadata service, lateral movement
Impact proof
Demonstrate reach, minimal footprint
Report
Attack narrative, severity, fixes
Retest
Confirm each fix actually closes the path
Rules of engagement first
Before any test we agree in writing on scope, the cloud provider's current testing policy, the environment (a production-equivalent staging environment whenever possible), data handling with synthetic data only, and a named contact on each side with an emergency stop. A critical finding is reported immediately, not saved for the final report.
A report you can act on
Each finding includes reproduction steps, evidence, affected resources, a severity rating (CVSS as a starting point, adjusted for real exploitability and business impact) and a specific fix such as the IAM policy change or configuration flag. A finding is closed when we fail to exploit it again, not when a ticket is marked done.
Tools speed up enumeration. Judgment decides what matters.
Our usual kit includes Prowler and ScoutSuite for configuration auditing, Pacu and CloudFox for AWS enumeration and privilege-escalation analysis, kube-bench and Trivy for cluster and image checks, and Burp Suite, OWASP ZAP, ffuf and nuclei for the web and API layer. A scanner will report a hundred misconfigurations; a tester decides which three of them chain into something that matters.
Security findings feed back into the build. Because we also design and build cloud and device platforms, fixes land in the infrastructure-as-code and the application, not only in a report. Compliance frameworks such as SOC 2 and ISO 27001 often rely on test records like pen-test reports and vulnerability scans, and we keep those artifacts as a by-product of the work. Certification itself is a separate process performed by an independent assessor.
One discipline on its own, or a program alongside the build.
Cloud security assessment
Threat model, configuration review and authorized penetration test of accounts, APIs, containers and serverless, with a fix list and retest.
Security in your pipeline
SAST, dependency, secrets, IaC and image scanning wired into CI with sensible gates, tuned so developers trust the results.
Performance and resilience testing
Load, stress and spike scenarios, fault-injection experiments and measured restore tests, covered in the same program.
Want the full method, including load, stress and chaos testing? Read Cloud Testing in Depth: Penetration, Stress and Security Testing.
What people ask before scoping a cloud security test.
Do I need permission to penetration test my own cloud environment?
You need written authorization from the system owner and a defined scope, and the test has to follow the cloud provider's current testing policy. Providers generally allow customers to test their own resources within limits but restrict denial-of-service simulation and testing of shared infrastructure, so we read the policy before every engagement.
What is the difference between a cloud security assessment and a penetration test?
An assessment reviews configuration and architecture against known good practice and lists the gaps. A penetration test goes further and tries to exploit what it finds, to show which weaknesses chain into a real path to your data. We usually do both: the review informs where the test focuses.
Do you test in production?
Whenever possible we test a production-equivalent staging environment built from the same infrastructure-as-code. Where production has to be tested, we agree windows, rate limits and a stop condition in writing first.
Which clouds do you test?
AWS, Azure and Google Cloud, including Kubernetes and serverless workloads running on them.
Can you test an IoT or device platform backend?
Yes. Device backends add MQTT and certificate-based identity, OTA update paths and per-device isolation, and we test that each device identity can only reach its own topics and data.
Is a scan enough?
Scanners catch known patterns cheaply and we use them, but they cannot judge business logic or chain findings together. Authorization flaws in particular need a person acting as two different users or tenants and trying to cross the line.
Design side of the same problems.
Cloud & Device Platforms
Fleet management, telemetry pipelines and APIs, built with security architecture owned by a senior engineer.
See the capability →Multi-Tenant SaaS Architecture for IoT Platforms
Data isolation patterns, and the tradeoffs between shared, isolated and hybrid models.
Read the article →API Design for Device-to-Cloud Communication
REST, MQTT or both, and how design choices make authorization easier to get right.
Read the article →