Everything a digital health team needs to know about the Web Application Security Assessment (WASA) required for ABDM - what it is, who needs it, what auditors test at each milestone, how the process works, and how to get ready.
The Ayushman Bharat Digital Mission (ABDM), run by the National Health Authority (NHA), is India's programme to build an interoperable digital health infrastructure. Citizens get an ABHA (Ayushman Bharat Health Account) number and address, and can choose to link and share health records between hospitals, labs, pharmacies, insurers and their own health apps - always through consent.
Software and services connect to this network in one or more roles:
Because these systems exchange some of the most sensitive personal data there is, NHA expects the applications that connect to ABDM to demonstrate sound security before they reach the production environment. That is the purpose of the WASA.
WASA stands for Web Application Security Assessment. In the ABDM context it is a security audit of your application and its ABDM integration, performed by a CERT-In empanelled auditor, and documented in a report that you submit to NHA as part of the compliance process. A successful WASA is a precondition for going live on the ABDM production environment.
| Activity | What it answers | Who typically does it |
|---|---|---|
| WASA (security assessment) | Can the application and its ABDM flows be attacked or abused? Is patient data protected? | CERT-In empanelled security auditor |
| VAPT | Broader vulnerability assessment and penetration testing, which can include infrastructure and network. A WASA uses VAPT techniques scoped to the application. | Security auditor |
| Functional testing | Does each ABDM flow work as NHA specifies? | Your development / QA team |
ABDM integration is organised into milestones, each adding a capability to your application. The security assessment follows the same structure: for every milestone you implement, the auditor tests the flows and APIs that milestone introduces, on top of a common application baseline.
M1 lets your application create, verify and use ABHA numbers and addresses, typically during patient registration or login.
M2 lets your application link a patient's records to their ABHA and share health data (as FHIR bundles) when consent is granted.
M3 lets your application request records from other providers through the consent flow and display them.
M4 covers additional ABDM integrations beyond the core identity, provider and user flows - such as connecting to healthcare professional and health facility registries, or digital claims exchange. The exact scope depends on your platform and on NHA's current definition, so confirm it for your integration.
Patient-facing PHR and Health Locker apps, Scan & Share flows, notification subscriptions and programme integrations follow their own tracks.
The milestones you implement depend on the role your product plays. The table below shows the typical pattern. Treat it as a planning guide and confirm the exact requirement for your product with NHA.
| Product type | Typical milestones | Security assessment emphasis |
|---|---|---|
| Hospital / clinic software (HMIS, EHR / EMR) | M1 + M2 (often with registry integrations) | ABHA flows, care context linking, record push, callbacks |
| Diagnostic lab / LIMS | M1 + M2 | Report sharing, IDOR on patient reports, FHIR payloads |
| Insurer, analytics or referral platform | M1 + M3 | Consent artefacts, record fetch, storage of received data |
| Telemedicine / pharmacy app | M1 + M2, and M3 if it views external records | Prescription push, consent, mobile app security |
| PHR / Health Locker app | PHR track, usually with M1 and M3 elements | Patient consent management, mobile security, Scan & Share |
| Full platform | M1, M2, M3 and extended integrations (M4) | All of the above, plus end-to-end data-flow review |
Many teams certify the first milestones, go live, and add the next ones later. Plan for the security assessment to follow each addition - a single auditor who knows your application already makes that faster.
A thorough ABDM WASA combines a standard application baseline with ABDM-specific tests for each milestone in scope.
| Milestone | Flow / area | Example security tests |
|---|---|---|
| M1 | ABHA creation, verification, login | OTP bypass, enumeration, data leakage, token replay |
| M2 | Care context linking, record push, callbacks | IDOR, spoofed linking, SSRF via callback URLs, malformed FHIR / XML entity attacks |
| M3 | Consent request, record fetch, storage | Consent forgery and replay, access without valid consent, key handling |
| M4 | Registry and claims integrations | API authentication, credential handling, data exposure |
| PHR / Locker | Consent management, Scan & Share, notifications | Consent bypass, deep link hijacking, local storage leakage |
These are the issues that most often show up when digital health applications are assessed. Fixing them before the audit saves a full remediation cycle.
Changing a patient, care context or report identifier returns another patient's data because ownership is not checked on the server.
No rate limiting, predictable or reusable OTPs, and responses that reveal whether an account exists.
Records are returned without checking that a valid, unexpired consent with the right purpose exists.
Gateway client secrets and tokens embedded in mobile apps, front-end code, repositories or logs.
Webhook or callback endpoints that fetch attacker-supplied URLs, or accept unauthenticated notifications.
Malformed bundles that trigger entity expansion, injection or crashes, and payloads accepted without schema checks.
Outdated protocols, missing certificate pinning in mobile apps, and health records stored unencrypted.
Stack traces in responses and patient identifiers or record content written to application logs.
Bulk enumeration, repeated consent requests and workflow steps that can be skipped or replayed.
Share your architecture, the milestones you implement, your role (HIP / HIU / PHR), tech stack and the test environment. The auditor builds an API inventory and agrees the scope, schedule and test credentials with you.
The auditor reviews how you handle tokens, secrets, FHIR payloads and consent logic, to spot design-level weaknesses before active testing starts.
OWASP Top 10 testing plus ABDM-specific API tests for each milestone in scope, with mobile and infrastructure checks in parallel where applicable. Testing is done in a non-production environment with test data.
You receive findings with evidence, CVSS risk ratings and step-by-step fixes. Critical and high findings must be resolved before the final report is issued; good auditors support your developers during this phase.
Every fix is re-tested to confirm it works and has not introduced new issues. A closure letter documents the remediated findings.
The auditor issues the signed WASA report and the supporting documents, which you submit to NHA.
Work through this list first. Each item you close now is one fewer finding in the report.
A standard application usually takes 2 to 4 weeks end to end: scoping, testing, reporting, remediation support and re-testing. Platforms with several milestones, many integrations or a large number of findings can take longer. Fast-track options exist for tight go-live dates, but the remediation time you need depends mostly on how quickly your team can fix findings.
Because scope varies so much, reputable auditors quote after a short scoping call rather than from a fixed price list.
Use these questions to compare providers:
Signed report covering results for every milestone in scope, in NHA submission format.
Screenshots and request / response evidence organised by milestone.
Every finding with CVSS rating, impact and remediation steps.
Developer-level guidance and calls to help close findings quickly.
Confirmation that fixes work and findings are closed.
Report, evidence, closure letter and auditor certificate in one package.
Talk to ISECURION - CERT-In empanelled, ISO 27001:2022 certified - about the milestones you are certifying and get a scoped quote within 24 hours.
Serving digital health companies in Bangalore, Mumbai, Delhi, Hyderabad, Chennai, Kolkata and across India.