ABDM M1 WASA Audit: The Complete Guide to the Safe-to-Host Certificate (2026)

If your product creates or links ABHA numbers, moves health records as a HIP or HIU, or runs consent-manager flows, there is a security audit standing between your sandbox integration and production access. It is usually called a WASA — a Web Application Security Assessment — and the report has to come from a CERT-In empanelled auditor. This guide explains what the assessment actually covers, what the certificate has to say, how long it really takes, and where teams lose weeks.

What is WASA? (WASA full form in cyber security)

WASA stands for Web Application Security Assessment. It is a structured evaluation of how a web application holds up against real attack behaviour — across architecture, authentication, session handling, authorisation, business logic and the APIs underneath. In general enterprise use it is a procurement and compliance artefact: a framework-mapped report that maps each finding to a recognised control set such as the OWASP Top 10, OWASP ASVS or ISO/IEC 27001 Annex A.

In Indian digital health, WASA carries a second and more specific meaning. It is the name most auditors and integrators use for the security assessment behind ABDM milestone certification, and the signed output is the artefact teams file with NHA. You will see the same document called a WASA certificate, a web application security audit certificate, or a safe-to-host certificate. They refer to the same thing.

Why ABDM integrators need a WASA

The Ayushman Bharat Digital Mission is a national health-data exchange. An application joining it can create and link ABHA numbers, push clinical records as a Health Information Provider, pull them as a Health Information User, or broker consent between the two. Every one of those flows carries identifiable health data, which is sensitive personal data under the DPDP Act as well as clinically consequential.

So access is staged rather than open. An integrator builds against the ABDM sandbox, demonstrates that its flows work, and has its application security-assessed before it is allowed to touch production. The security evidence submitted at that gate is the WASA report and certificate, and the auditor signing it is expected to be CERT-In empanelled — the same empanelment regime that underpins regulator-facing audit work elsewhere in India. NHA publishes the resulting certificates for approved integrators, which is the clearest public signal of what the process expects.

ABDM milestones M1, M2 and M3

Who needs an ABDM WASA

• HMIS and hospital information systems adding ABHA linkage or record sharing
• EMR and clinic-management products used by ABDM-registered facilities
• PHR applications and health lockers holding records on the patient's behalf
• Health Information Providers — diagnostics chains, hospitals, radiology and pathology platforms pushing records
• Health Information Users — insurers, teleconsultation platforms and care-coordination products retrieving records
• Consent managers and any intermediary generating or validating consent artefacts

Emphasis shifts with the role. A HIP is examined hardest on linking and push. An HIU is examined hardest on consent handling and fetch. A health locker gets both, plus the patient-facing consent interface, because that is where a confused or misleading UI turns into a consent that was never meaningfully given.

What the assessment covers

An ABDM WASA runs on two tracks at once. The functional track proves the integration behaves the way the specification says it should. The security track tries to break it. Both matter — a perfectly secure application that mishandles consent artefacts is not compliant, and a functionally flawless one with an IDOR on a record endpoint is worse.

The safe-to-host certificate: what it must say

The certificate is short, and the detail that matters most is which environment was actually assessed. If testing was performed against staging rather than production, the certificate is expected to state that explicitly. This is not a formality — a staging environment frequently differs from production in exactly the ways that matter, including TLS termination, WAF placement, debug verbosity and whether test data or live records are in play.

A complete submission bundle typically includes more than the certificate itself:

• The WASA report, signed by the CERT-In empanelled auditor
• Functional test evidence — request and response logs mapped to the checklist
• A security findings report with severity ratings, commonly CVSS
• A closure or re-test letter confirming that findings were remediated and verified
• The application and environment details the certificate refers to

How long it takes

The assessment itself is not usually the long pole. Scoping, functional testing, security testing and a draft report commonly run two to four weeks for a mid-sized application. What determines the real end-to-end date is remediation: findings have to be fixed and then re-tested before a clean certificate can be issued. Teams that budget only for the assessment are the ones that miss their date.

Published estimates vary — you will see three to six weeks and five to eight weeks quoted by different auditors — and the spread is almost entirely remediation speed, not methodology. Plan against your own engineering capacity to turn around fixes, not against the shortest number you read.

WASA vs a penetration test vs VAPT

These overlap enough to cause confusion at procurement, and the difference is mostly one of purpose. A penetration test asks whether something can be exploited. A VAPT combines vulnerability assessment breadth with penetration-test depth. A WASA asks a wider question — whether the application's design and controls hold up, mapped to a framework, in a form somebody else will accept as evidence.

For ABDM the distinction is practical rather than philosophical: the submission expects a WASA-shaped deliverable with functional evidence alongside the security findings. A pure penetration-test report, however good, is not the same document. If you already run an annual pentest, that work is not wasted — it substantially reduces what a WASA finds — but it does not replace the submission.

For a fuller treatment of the general distinction, see VAPT vs Red Team and the Penetration Testing and VAPT guide. For the empanelment regime itself, see the CERT-In empanelled audit guide.

What sends teams back for a re-test

1. Authorisation trusting a client-supplied identifier — the single most common cause of a failed record-access test
2. Consent artefacts that can be replayed, or whose scope and expiry are not enforced server-side
3. Tokens that outlive the consent they were issued under, or revocation that does not actually revoke
4. Verbose errors returning stack traces or internal identifiers from health-record endpoints
5. TLS configuration that passes a browser but fails a configuration review — weak ciphers, missing HSTS, mixed content
6. Rate limiting absent on ABHA lookup or record-fetch endpoints, making enumeration cheap
7. Assessing staging, then discovering production differs in a way that invalidates the evidence

Choosing an auditor

• Confirm CERT-In empanelment is current — CERT-In publishes the empanelled list; check it rather than taking a logo on a website at face value
• Ask whether the team has actually tested ABDM flows before, not just web applications generally — consent artefacts and FHIR payloads are specific
• Agree up front which environment will be assessed, and what the certificate will say about it
• Confirm that re-testing of Critical and High findings is included rather than billed separately
• Ask what the deliverable bundle contains, and check it against what you actually have to submit