Bharat Cyber Solutions provides WASA assessment for ABDM-integrated applications — including HIMS, PHR apps, Health Lockers, NHCX APIs and Connectors — supporting readiness across the M1, M2 and M3 milestone journey with a structured Sandbox Exit Ready approach.
ABDM, run by the National Health Authority, links hospitals, labs, pharmacies and insurers through the ABHA health ID. Before any app can touch that network in production, it has to clear Milestone 1 — a combined functional and security review carried out by a CERT-In empanelled auditor.
No app reaches ABDM production without a passing M1 report — it's a hard requirement, not a recommendation.
Health records are among the most sensitive data a system can hold — testing checks they stay that way.
ABDM's whole model rests on patient consent — we test that grant, revoke and expiry can't be forced or faked.
ABDM runs on a dense API layer — every endpoint is checked for authentication gaps, logic flaws and injection.
Every organisation that connects to the ABDM network — as a data source, a data requester, or a health record locker — has to clear this milestone before going live.
Hospitals, clinics, diagnostic labs and pharmacies that generate patient records and push them onto ABDM.
Insurers, doctors and healthcare platforms that request and consume records through patient consent.
Personal health record apps that store and manage documents tied to a patient's ABHA ID.
Electronic record software makers integrating their platforms directly with ABDM's API layer.
Online consultation services that generate prescriptions and records and push them into ABDM.
Digital pharmacies and health insurance platforms drawing on patient data through ABDM.
ABDM certification is milestone-based. M1 is the security and functional gate we handle for you — here's how it connects to what comes after.
The combined functional and security review of your ABDM-integrated application — ABHA registration and linking, consent management, health data API security, OWASP Top 10 coverage, authentication and encryption. A passing report from a CERT-In empanelled auditor is what unlocks M1 certification and production access.
Once you're live, NHA looks at how much real activity your app is driving — records linked, consents processed, exchanges completed. We can help make sure the API implementation behind those numbers stays secure as usage scales.
Full integration at scale, with measurable impact for patients and providers. The controls put in place at M1 are what this stage builds on — so getting M1 right the first time pays off later.
End-to-end functional and security testing mapped to NHA's M1 requirements — not a generic web app scan re-labelled for healthcare.
Functional and security testing of ABHA creation, verification and linking, checked against identity manipulation attempts.
Grant, revoke and expiry flows verified for correctness, then tested against bypass and forged-consent scenarios.
Fetch and push APIs checked for FHIR validation, data completeness, and authentication or injection weaknesses.
Injection flaws, broken authentication, access control gaps, XSS and the rest of the OWASP list, applied to your build.
OAuth 2.0 / OpenID Connect implementation, token handling and session expiry checked against hijacking and replay.
TLS configuration, data-at-rest encryption and key management checked against NHA and MeitY expectations.
Rate limiting, IDOR, parameter tampering and ABDM-specific logic abuse, tested endpoint by endpoint.
For ABDM-linked Android and iOS apps — local storage, deep links, certificate pinning and SDK implementation.
Security policies and technical controls checked against NHA's requirements, then packaged for submission.
NHA expects every ABDM flow to behave correctly, not just resist attack. We test both dimensions in one engagement.
| ABDM flow | What we test | Security checks |
|---|---|---|
| ABHA registration | OTP-based creation, address auto-fill, ABHA number generation | OTP bypass, enumeration, rate limiting ✔ |
| ABHA linking (HIP) | Record linking, care-context discovery, demographic matching | Unauthorized linking, IDOR on care contexts ✔ |
| Consent request (HIU) | Request creation, notification delivery, artefact generation | Consent forgery, replay attacks ✔ |
| Consent grant / revoke | Grant and revoke via PHR app, expiry, purpose enforcement | Consent bypass, expired-consent abuse ✔ |
| Health record fetch (HIU) | Post-consent record requests, FHIR bundle delivery | Access without valid consent, FHIR injection ✔ |
| Health record push (HIP) | Structured FHIR push, document type and timestamp checks | Malformed payloads, unauthorized push ✔ |
| Gateway authentication | Client credential flow, token usage, session handling | Token leakage, replay, insecure storage ✔ |
| Error handling | Invalid inputs, partial consent, timeout recovery | Verbose errors, stack trace exposure ✔ |
Seven steps, each one built around what NHA actually checks when your submission lands on their desk.
We map your ABDM integration type, tech stack and API inventory, and confirm sandbox access and test data.
Your integration code and FHIR structure are reviewed against NHA specifications before active testing starts.
Every ABDM flow — ABHA creation, linking, consent, record fetch/push — is validated against NHA's checklist. Note: we are not doing FT Testing.
OWASP Top 10, ABDM-specific API tests and mobile testing (where applicable) run in parallel.
Findings come with clear evidence, risk ratings and remediation guidance your developers can act on directly.
We re-test every fix and issue a formal closure letter — a required piece of the NHA submission package.
The full WASA report, evidence, closure letter and submission bundle, signed and ready to send to NHA.
Nothing left for you to assemble — the full bundle arrives ready to send.
Formatted for NHA submission and signed by a CERT-In empanelled auditor.
Screenshots, API logs and pass/fail status mapped to NHA's M1 checklist.
OWASP and ABDM-specific findings with CVSS ratings and remediation guidance.
Formal re-test confirmation for every remediated finding, required for submission.
Yes. NHA won't grant M1 certification or production access without a passing WASA report from a CERT-In empanelled auditor. It's a hard prerequisite, not a best practice.
Functional testing confirms your ABDM integration works as specified — ABHA creation, consent, record exchange. Security testing checks those same flows can't be attacked or bypassed. NHA requires both, and we run them together.
Standard applications typically take 2–4 weeks end to end, covering scoping, testing, reporting, remediation support and re-testing. Larger or more complex platforms can run 4–6 weeks. Fast-track options are available for tight go-live dates.
Sandbox only, as NHA mandates. No real patient data is ever exposed during the assessment. Once M1 is granted, the application can then move to the ABDM production environment.
Yes — engagements run pan-India with a fully remote-capable process, so location isn't a constraint on timelines or quality.
Cost depends on application complexity, the number of ABDM APIs in scope, and whether mobile testing is included. Share a few details in the form below and we'll come back with a clear, itemised quote.
A quick, no-obligation look at your application before we scope any work.
