Patient portal assessment
Multi-role testing across patient, proxy and clinician accounts, with cross-access attempted between them, as in our healthcare security case study.
Patient portals, scheduling systems, clinical APIs, payer integrations: all of it holds data that carries a lifetime of consequence if it leaks, and much of it runs on systems that cannot be taken offline for a test.
AIPTx tests inside a scope you define, with destructive actions off by default and a request rate you control.

Healthcare has the hardest security operating constraint of any sector: the systems cannot stop.
A retailer can take a checkout offline for twenty minutes. A hospital cannot take the electronic health record offline at all, and the practical consequence is that a great deal of clinical infrastructure is tested rarely, patched slowly, and assessed with extreme caution when it is assessed at all.
Around that core sits a fast-moving external attack surface that behaves nothing like it.
Patient portals, telehealth platforms, appointment booking, prescription refill, payer eligibility APIs, and a growing tier of digital health services built by teams that ship weekly. Two organisations, one network.
The data at the centre is also uniquely durable. A payment card is reissued in days. A diagnosis, a genetic marker or a mental health record is permanent, which is why healthcare records retain value long after other stolen data has expired.
Any testing approach that carries a plausible risk of disruption will be refused, correctly. This is the constraint every other decision follows from.
Software validated for clinical use, sometimes running on operating systems past support, where modification may require revalidation. The vulnerability is understood and the fix is not straightforward.
Authentication, record access, document handling, messaging, payments, proxy access for a parent or carer. Every access-control pattern that causes trouble elsewhere exists here, over data with the highest sensitivity.
Parents accessing a child's record, carers accessing a dependant's, clinicians accessing by care relationship rather than by static role. This is an authorisation model far more complex than most applications carry, and complexity is where authorisation fails.
Payer eligibility checks, laboratory results, pharmacy systems, referral networks, health information exchanges. Data crosses organisational boundaries constantly, and each crossing is a trust relationship.
Many clinical environments were built for reliability and reachability rather than segmentation. A foothold on a workstation reaches further than it should, which is exactly what attack chain analysis maps.
Health system security teams are typically small relative to the surface they own, and the surface grows with every acquired practice and every new digital service.
Destructive actions are disabled by default. The agent will not delete data, run denial-of-service payloads or exhaust resources. Every run is bound by a request rate you set, and out-of-scope paths are declared and respected. Exploitation demonstrates access (retrieving one record, reading a token) rather than causing damage.
For clinical environments, the practical pattern is to test the patient-facing and integration tiers directly, run perimeter-limited checks against clinical infrastructure, and use a pre-production copy where one exists.
Configure patient, proxy, clinician, scheduler and administrator, and the agent cross-tests them. A proxy account reaching a record outside its delegation, or a clinician role reaching a patient outside their care relationship, is only detectable when a tool holds both sessions and compares what each can reach.
Findings include sensitive values returned where they should not be (identifiers, tokens, personal data), plus PII detection and verbose error monitoring. An endpoint that behaves correctly but returns more than it should is a disclosure, and it is easy to miss when only status codes are checked.
Findings map to HIPAA alongside SOC 2, ISO 27001, GDPR, NIST and CIS, with control assessment and gap analysis in the reports. For organisations that also handle payment, PCI DSS mapping is included.
The AIPTx agent deploys via Docker with outbound connectivity only, covering internal ranges: port and service detection, version detection, CVE matching, TLS posture and default credentials. On a flat clinical network this is usually the first honest inventory the team has had.
Every confirmed finding carries the exact request, the response proving it worked, and a reproducible curl command, plus remediation guidance with vulnerable and secure code examples. Where a team is small, the cost of triage is the binding constraint, and evidence is what removes it.
Bearer, basic, cookie, custom header and OAuth2/OIDC, with scripted login support and sessions maintained across the run.
The class that matters most for record access.
Imported from a spec where one exists and discovered from live traffic and client bundles where it does not, which is how an integration endpoint nobody has documented since the vendor built it gets tested at all.
Healthcare API security testingRecords leak most often in passing: an identifier in an error page, a patient quoted back in a stack trace, a field returned to a role that should never have been able to request it.
Deployed inside the network with outbound connectivity only, so no inbound rule is opened for it. Port, service and version detection, CVE matching, TLS posture and default credentials across the ranges you declare.
A session that survives a logout on a shared clinical workstation is an access control problem long before it is a session problem, and it is the one a busy ward reproduces daily.
The mapping lands in the same report as the technical detail and the retest history, so the evidence that testing happened and the evidence that something was fixed are one document rather than two exports.
The conservative defaults are what make a first assessment schedulable against a live estate, rather than deferred to a maintenance window that never quite arrives.
Multi-role testing across patient, proxy and clinician accounts, with cross-access attempted between them, as in our healthcare security case study.
Full assessment of a new service before it carries clinical traffic.
Testing the API surface exposed to an external partner before the connection is enabled.
A Deep assessment with control mapping and retest history attached to the evidence pack, kept current between audits with continuous security validation.
Agent-based assessment of a clinical network to establish what is actually running and what a foothold would reach.
Assessing an acquired practice's systems before they are connected to the main estate.
FAQ
Yes, in a correctly configured environment. AIPTx leaves destructive actions switched off by default: the agent will not delete data, execute denial-of-service payloads or exhaust resources. You define the request rate and declare out-of-scope paths, and the platform adheres to them. Exploitation is about proving access, such as reading a single record, not about causing damage. Most healthcare organisations test patient-facing applications and integration systems directly, and run perimeter-limited tests against clinical infrastructure.
It supports your HIPAA programme, but cannot deliver compliance on its own. AIPTx maps every finding to HIPAA controls, with control assessment and gap analysis in the report, alongside SOC 2, ISO 27001, GDPR, NIST and CIS โ and PCI DSS if you process payments โ giving you technical evidence of testing and remediation for an audit. HIPAA covers more than technical controls, and no testing tool delivers a compliance programme by itself.
Yes, at the network layer. The internal agent assesses hosts and services regardless of how old the application is, covering port and service discovery, version detection, CVE matching, TLS posture and default credentials. Application-layer testing depends on what the system exposes over HTTP. Where a system cannot be updated or modified, the assessment still shows precisely what exposure is present, so compensating controls can be applied accurately.
AIPTx uses test accounts for each role, such as patient, proxy (parent or carer), clinician, scheduler and administrator, and attempts cross-account access between them. Can a proxy account reach a record that was not delegated to it? Can a clinician reach a patient outside their care relationship? These IDOR and privilege escalation flaws are only visible when a tool holds active sessions in several accounts at once and compares what each can reach.
It depends on how deep you need to look. A Quick Scan runs in 15 to 30 minutes and suits a pipeline gate; a Standard assessment runs in 1 to 4 hours and is the working depth for authenticated coverage; a Deep assessment runs from 4 to 24 hours, because chained exploitation is sequential and cannot be compressed. The request rate is set separately from the depth, so a long run against a live estate can be slowed to a low-impact pace that avoids disrupting operations. To see what the output looks like, see a sample assessment report.
Network-connected devices are reported as hosts and services within the internal network assessment. Device firmware and embedded protocol testing is not a documented capability, and device software is often subject to regulatory constraints that limit what any testing tool should attempt.
Scope-bound, non-destructive assessment with HIPAA control mapping and evidence on every finding. View pricing.
Destructive actions off by default ยท Scope verified before any test runs
Same engine, different threat model, different auditor. Each page covers the systems, regulations and attack paths that sector actually lives with.
Payment flows, lending decisions, account servicing, open banking APIs โ the logic that handles money is the logic attackers study hardest. It is also the logic no signature database describes.
Financial Services Security TestingGovernment penetration testing for benefits portals, licensing systems, tax filing and records access โ services that must be open to everyone by design, running on estates that were often built decades apart and connected later.
Government Security TestingAlmost nobody breaks into a plant by attacking a controller. They arrive through a corporate account, a supplier portal, an ERP integration or an exposed remote access service, and then walk into a network that was designed for reliability, not for containment.
Manufacturing Security TestingThe vulnerabilities that cost retailers money are rarely exotic. A discount that stacks when it should not. A price accepted from the client. A gift card balance that survives a concurrent request. A loyalty account reachable from another customer's session.
Retail Security TestingEvery enterprise deal arrives with a questionnaire, a SOC 2 request and someone technical asking when you last tested. Meanwhile you ship on Tuesday and again on Thursday, and the last pentest describes a product that has since changed twice.
SaaS Security TestingA single authorisation flaw in a subscriber portal is not one exposed account. At operator scale it is a data set โ and the same flaw in a provisioning API is an operational one.
Telecom Security TestingA department stood up a project site in 2019. A research group runs its own server. A faculty subdomain points at infrastructure that was decommissioned two years ago. None of it went through central IT, and all of it is reachable.
Education Security TestingClients do not retain a firm because of its document management system. They retain it on the assumption that what they share stays privileged โ and increasingly they audit that assumption before instructing.
Legal Security Testing