The Mandatory Shift Toward Ayushman Bharat Digital Mission
By 2026, ABDM integration is not a differentiator you put on a pitch deck. It is a regulatory prerequisite for any HealthTech platform, EMR or HMIS product, or diagnostic network operating in India. Hospitals empanelled under PM-JAY and CGHS are required to run ABDM-compatible software, which means procurement conversations now open with a certification question rather than a feature comparison. If your product cannot show cleared milestones, it does not reach the shortlist.
The Ayushman Bharat Digital Mission is the National Health Authority’s digital health ecosystem. It connects patients, doctors, hospitals, labs and HealthTech platforms through a shared set of registries and APIs, built around the 14-digit ABHA identifier, the Health Facility Registry, the Healthcare Professional Registry, and a consent framework that governs how records move between institutions.
Because ABDM handles sensitive health data, the government does not let arbitrary software connect to its APIs. Every platform has to build against the sandbox, prove each capability works, and pass through a certification gate before it receives production credentials.
That gate is structured as three sequential milestones. M1, M2 and M3 each cover a distinct capability layer; each has to be integrated and demonstrated in the sandbox, and each has to be cleared before the next becomes meaningful. Certification attaches to the software, not to the hospital, which is why the burden sits with you as the vendor rather than with your customers.
The Milestone Breakdown: What M1, M2 and M3 Actually Require
M1: identity and patient discovery
M1 turns your platform into an identity participant. You implement ABHA creation and verification, OTP-based authentication flows, patient discovery, and registration against the Health Facility Registry and Healthcare Professional Registry.
In practice, this is the most approachable milestone. Your system can accept ABHA-linked patients and start building an ABHA-mapped patient base. What it cannot do yet is move a single health record.
M2: becoming a Health Information Provider
M2 is where most teams lose their schedule. You become a HIP, which means implementing care context creation, linking clinical records to a patient’s ABHA, generating FHIR R4 bundles against India-specific profiles, and wiring up consent manager integration so records only move when the patient has authorised it.
The FHIR work is the hard part. You are mapping your existing data model onto resources like Patient, Practitioner, Encounter, Observation, Condition, MedicationRequest, DiagnosticReport, DocumentReference and Procedure. Teams with clean, normalised clinical data move through this in weeks. Teams whose lab results live in a free-text notes field do not.
Consent handling, encryption and audit logging all land here too, which makes M2 the milestone with the largest security surface.
M3: becoming a Health Information User
M3 lets your platform fetch and display records held by other facilities in the network, subject to patient consent. Clinically, this is where the value shows up, because a doctor can pull a patient’s history from any ABDM-connected provider instead of ordering duplicate tests.
Security-wise, M3 raises the stakes considerably. Your platform is now handling records that belong to other institutions, retrieved under a consent artefact you are obliged to honour precisely. An access control flaw at M1 exposes your own data. The same flaw at M3 potentially exposes records pulled from across the network.
A note on scope: M4 exists and covers digital insurance claims through NHCX, but M1 through M3 are what determine whether your platform is functionally usable in the ABDM ecosystem.
The Step-by-Step ABDM Integration Checklist
Work through this ABDM integration checklist in order, because skipping ahead is how teams end up rebuilding.
- Register your software on the ABDM sandbox and obtain your bridge ID
- Target ABDM V3 APIs, since v0.5 and v1.0 are legacy and new development against them is wasted effort
- Complete HFR and HPR registration flows
- Build and test ABHA creation, verification and OTP authentication, then pass every NHA M1 test case
- Map your clinical data model to FHIR R4 with India-specific profiles before writing integration code
- Implement care context linking and record generation for M2
- Integrate the consent manager and verify that no record moves without a valid consent artefact
- Implement HIU record fetch flows for M3, including consent request and revocation handling
- Build audit logging that captures who accessed which record, when, and under which consent
- Confirm encryption in transit and at rest across every path that touches health data
- Run internal security testing before you book external testing, because finding your own broken access control is cheaper
- Book functional testing with an NHA-empanelled agency and expect the first attempt to surface issues
- Commission a web application security audit from an empanelled agency and obtain your Safe-to-Host certificate
- Submit the functional testing report, the Safe-to-Host certificate and your application summary to NHA
- Register your facility on HFR against production credentials and prepare for go-live
Two items on that list consistently take longer than teams plan for: the FHIR mapping and the security audit. Both are worth starting earlier than feels necessary.
The Non-Negotiable Role of VAPT in NHA Production Approval
Here is the part that catches teams by surprise. Clearing all three milestones in the sandbox does not get you production credentials. Independent functional testing and a web application security audit sit between you and go-live, and the Safe-to-Host certificate that audit produces is a hard requirement rather than a formality.
The audit covers the OWASP Top 10 in full, along with authentication and session management, and it has to come from an empanelled agency. A resubmission after failed findings typically adds two to four weeks, which is why a failed audit is usually a launch delay rather than a paperwork inconvenience.
Automated scanning alone does not get you through this. Scanners are genuinely useful for what they cover: missing patches, outdated libraries, weak ciphers, known CVEs, absent security headers. What they cannot do is understand what your application means.
Consider what that limitation looks like against ABDM M3 compliance specifically. A scanner sends an authenticated request to a record-fetch endpoint and receives a 200 response with a valid FHIR bundle. To the tool, that is the application working correctly. It has no way to know that the consent artefact referenced in the request belonged to a different patient, or that the requesting practitioner was never authorised for that care context, or that a revoked consent still returns data because revocation was implemented as a soft flag rather than an enforced check.
Those are logic flaws. They require a human who understands the consent model to sit down and try to break it.
A tester’s view from the field
The following reflects patterns our testers encounter on healthcare engagements.
The finding that shows up most often in healthcare work is not exotic. It is API security risks like broken access control, and it hides behind an interface that looks correct.
A typical pattern: the platform authenticates properly, the login flow is solid, MFA is enabled, and the front end only ever displays records the logged-in user should see. Everything looks right in a browser. Then you intercept the request behind the record view, change a single identifier in the API call, and the backend returns someone else’s data without complaint. The front end was doing the authorisation. The API was doing none.
That flaw does not appear in a scanner report, because every request in the sequence is technically well-formed and technically authenticated. It appears when a person asks a question the tool cannot formulate: should this specific user, holding this specific token, be allowed to see this specific record?
On an ABDM platform, that question has a legal dimension. A record fetched without valid consent is not just a bug. It is a consent framework failure on data that belongs to another institution and a patient who never agreed to the disclosure.
HealthTech Vulnerabilities and DPDP Act Alignment
Health data sits in the most sensitive category the DPDP framework contemplates, and the timeline is now close enough to matter for anything you build this year. The DPDP Rules were notified on 13 November 2025. Enforcement powers and penalties activate on 13 November 2026, and full substantive compliance is due 13 May 2027. The penalty ceiling for failing to implement reasonable security safeguards is ₹250 crore, and penalties stack per violation category rather than per incident.
The link to your ABDM work is direct. The security controls the NHA audit examines are the same controls that evidence reasonable safeguards under DPDP. Broken access control on a record endpoint is simultaneously an audit finding, a consent framework failure, and after November 2026, evidence in a penalty proceeding.
A recent Qualysec engagement with an Indian IP-led healthtech company shows what this looks like in practice. The client, a 53-person team building an AI-driven healthcare platform focused on governance, compliance and real-time analytics, commissioned testing across three public-facing websites and their network IP infrastructure. The assessment surfaced 29 vulnerabilities. The five most significant are worth reading closely, because every one of them has an ABDM analogue:
Reflected cross-site scripting, rated critical.
Malicious scripts could be injected through URLs or input fields and execute in a victim’s browser the moment they clicked a crafted link, opening a path to session hijacking and credential theft.
HTTPS not enabled, rated high.
One or more public-facing sites were serving traffic unencrypted. On a platform handling health records, that means interceptable patient data.
SQL injection, rated high.
Unsanitised input allowed direct manipulation of backend database queries, putting patient records at risk of unauthorised access, modification or deletion.
Broken access control, rated medium.
Users could reach resources beyond their permission level, including records belonging to entirely different patients.
Missing security headers, rated medium.
Absent standard HTTP headers left browsers exposed to clickjacking, MIME sniffing and script injection.
Look at the fourth item and imagine it on an M3-certified platform. Records belonging to different patients, reachable by users without the right permissions, in a system whose entire purpose is fetching health data from other institutions under consent.
The engagement did not end at the report. Every finding went through root cause analysis rather than surface patching; the security team worked directly with the client’s developers on remediation, and a three-phase retesting process confirmed each fix held and introduced nothing new. The result was zero open critical issues.
Fast-Tracking NHA Production Exit with Qualysec’s VAPT
- ABDM-aligned security testing. Testing is scoped against the control areas your security audit will examine, with particular attention to the consent enforcement, access control and audit logging that M2 and M3 introduce. Findings are documented in a form your assessor expects to read, which reduces back-and-forth at submission. Qualysec holds CREST accreditation awarded in 2025, along with ISO 27001:2022, ISO 9001:2015 and ISO 13485:2016, the last of which is built specifically for medical device and healthcare quality management.
- Manual-first penetration testing. Automated tooling establishes the baseline quickly, then experienced testers work the application by hand: manipulating consent artefacts, attempting horizontal and vertical privilege escalation across care contexts, testing whether revoked consent actually revokes, and chaining findings the way a real attacker would. This is where broken access control gets caught.
- Zero false positives and clear remediation. Findings arrive validated, so your engineers spend their time fixing rather than triaging noise. Each issue carries reproduction steps, root cause, and a specific fix path. That distinction matters more than it sounds when your team is trying to close findings inside a two to four-week resubmission window.
- Complimentary patch retesting. Verification is included rather than invoiced separately. Fixes get retested, regressions get caught, and you receive the closure evidence your submission needs. The healthcare engagement described above ran three retesting phases at no additional cost.
Conclusion
The teams that clear this cleanly treat security as part of the build rather than a gate at the end. They map FHIR resources before writing integration code; they enforce authorisation at the API rather than in the interface, they log every consent-governed access, and they book their security audit early enough that a failed finding costs a sprint instead of a quarter.
Approached that way, ABDM certification stops being an obstacle between you and revenue. It becomes the credential that gets your product onto hospital shortlists, and the security discipline that keeps patient data intact once it is there.
Talk to Qualysec about a manual-first assessment scoped to your NHA submission timeline.
Frequently Asked Questions
Can a HealthTech platform go live with just M1 compliance?
Technically yes, but the platform will have very limited utility. M1 only enables ABHA creation, verification and patient discovery, so you can register ABHA-linked patients without moving any health records. Genuine paperless workflows, incentive eligibility and the clinical value of shared patient history require M2 and M3.
Does an automated vulnerability scan satisfy the NHA’s VAPT requirement?
No. The security audit must be conducted by an empanelled agency and cover the full OWASP Top 10 alongside authentication and session management, which requires manual validation. Automated scanning cannot detect the consent enforcement and access control flaws that matter most on an ABDM platform, because those requests look legitimate to a tool.
How long does sandbox evaluation and production exit typically take?
Plan for six to nine months across M1 to M3 for a greenfield build, or four to six months if you are layering onto an existing system with a structured integration layer. M2 alone commonly runs four to twelve weeks depending on how clean your clinical data is, and functional testing failures or security audit resubmissions add two to four weeks each.
