The ABHA WASA audit process, phase by phase

No digital health application can move from the ABDM sandbox into production without a passing Web Application Security Audit (WASA) report and a Safe-to-Host certificate signed by a CERT-In empanelled auditor. The National Health Authority grants the certification, but it will not do so without that auditor’s signed attestation that the application is free of known vulnerabilities and safe to host.

This guide sets out, in operational detail, how a digital health application actually gets there: the eight phases of the audit, who does what at each stage, what the auditor signs at the end, and the preparation that separates a three-week engagement from a three-month one. It is written for the applicant preparing for certification, a hospital, HealthTech product company, HMIS/HIS vendor, HIP or HIU, as much as for the team executing the audit.

Where WASA sits in the ABDM journey

ABDM certification is milestone-based and strictly sequential. WASA is the security gate between a functionally complete sandbox application and production access, it cannot run in parallel with milestone work, and it cannot be skipped.

1. Develop. Sandbox integration — M1 / M2 / M3 milestone APIs implemented and NHA-approved.
2. Validate. Functional testing — an NHA-empanelled agency validates workflows against the official test cases.
3. Audit — this guide. WASA security audit — the CERT-In empanelled auditor performs full VAPT, remediation support and revalidation.
4. Submit. NHA document review — the sandbox-exit bundle is submitted via the ABDM portal.
5. Go live. Production access — credentials issued and the environment switches from sandbox to production.

A common and costly misconception. ABHA/ABDM security certification runs on the CERT-In empanelment track, not the UIDAI/Aadhaar AUA-KUA track. They are separate compliance regimes — selecting a non-CERT-In auditor is one of the most frequent causes of NHA rejection and multi-week delay.

Why a CERT-In empanelled auditor specifically

CERT-In, under MeitY, maintains the national panel of accredited security auditors. In the ABDM ecosystem its role is structural rather than incidental:

• Empanelment of auditors. CERT-In accredits and periodically re-certifies the agencies authorised to perform WASA. NHA accepts security attestations only from this pool.
• Definition of standards. The audit is benchmarked to CERT-In guidelines and the OWASP Top 10 (2021), layered with ABDM’s own security requirements and the HDM Policy 2020.
• Compliance oversight. CERT-In oversees adherence to security protocols across the ecosystem and provides guidance to developers and auditing organisations.
• Assurance of independence. The auditor must be independent of the application’s development. The signed Safe-to-Host certificate carries the auditor’s empanelment identity.

Verify before you engage. Confirm your auditor’s name and empanelment ID directly on the official CERT-In empanelled-auditors list, and confirm prior ABDM/ABHA experience — HIP, HIU, consent-artefact and FHIR concepts should not need explaining. SICHERTEN is CERT-In empanelled; our empanelment reference is provided in the engagement proposal and is independently verifiable on the CERT-In site.

The audit, phase by phase

Eight phases, each with an objective, the applicant’s responsibilities, the auditor’s work and a deliverable that closes it. Durations below are indicative for a medium-complexity application.

Phase 0, Engagement initiation & NDA (2–4 days)

Contracting, scoping intake, confidentiality, audit-window booking

The engagement is contracted and a mutual NDA executed before any credential or artefact changes hands — health data and pre-production vulnerabilities are both highly sensitive. Because empanelled-auditor bandwidth is finite and fills near quarter-ends, the audit window is booked while the applicant is still completing M3 and functional testing.

• Client: Sign NDA & SOW; nominate a single technical point of contact; confirm the target environment.
• CERT-In auditor (SICHERTEN): Issue SOW & NDA; assign lead auditor and independent reviewer; evidence empanelment validity.

Deliverable: Signed SOW & NDA; named engagement team with CERT-In empanelment reference; booked audit window.

Phase 1, Scoping & reconnaissance (2–3 days)

Understand architecture, data flows and ABDM integration points; fix the assessment boundary

The auditor builds a precise picture of what is being tested before testing begins. This is where over-broad or under-broad scope — a frequent cause of rework — is prevented.

• Review of architecture and design documentation, data-flow diagrams and the ABDM sandbox credentials.
• Identification of every data-handling component: ABHA number creation and verification, consent-manager (HIE-CM) APIs, FHIR R4 data exchange, care-context linking, HFR/HPR touchpoints.
• Enumeration and mapping of all endpoints, APIs, third-party integrations, and the web and mobile interfaces in scope.
• Definition of boundaries: environment, internal vs external components, the API layer, authenticated vs unauthenticated surface.
• Threat modelling of ABDM-specific abuse cases — consent-artefact forgery, cross-patient data access, linking-token replay.

• Client: Provide architecture docs, data-flow diagrams, sandbox credentials, test accounts for every role, and the API collection (OpenAPI/Postman).
• CERT-In auditor (SICHERTEN): Produce the Audit Scope Document; agree rules of engagement and the testing window.

Deliverable: Audit Scope Document (ASD) — assets, environments, roles and the assessment boundary, countersigned by both parties.

Phase 2, Vulnerability assessment (automated) (2–4 days)

Broad identification of known vulnerabilities across all layers

A breadth-first pass using industry-standard tooling to surface known and low-hanging issues quickly, so manual effort in Phase 3 concentrates on depth. Automated findings are treated as leads, not conclusions — each is manually validated to remove false positives.

• Typical tooling: Burp Suite Professional, OWASP ZAP, Nessus, Nikto, Nmap, plus TLS and dependency/SCA scanners.
• Coverage: network and host configuration, TLS posture, the web/API layer, and the third-party component inventory.

• Client: Keep the sandbox build stable and available for the agreed window; freeze deployments.
• CERT-In auditor (SICHERTEN): Run authenticated & unauthenticated scans; triage and de-duplicate; validate every candidate finding.

Deliverable: Preliminary findings register (validated automated results, false positives removed).

Phase 3, Penetration testing (manual) (5–8 days)

Depth-first exploitation and business-logic testing — the heart of the audit

This is the phase that surface-level “48-hour” audits skip and that NHA reviewers most reliably catch. A manual, business-logic-aware tester examines the OWASP Top 10 and, critically, the ABDM-specific logic that automated tools cannot understand. Both logged-in and non-logged-in perspectives, and every distinct user role, are tested.

• Client: Be reachable for clarifications; do not push code changes mid-test unless coordinated.
• CERT-In auditor (SICHERTEN): Manually exploit and evidence each finding; assign CVSS severity; capture reproducible proof-of-concept.

Deliverable: Complete findings set — each with CVSS severity, reproduction steps, evidence and business-risk articulation.

Phase 4, ABDM compliance mapping (1–2 days)

Confirm alignment with ABDM specifications, FHIR standards and HDM Policy 2020

Running alongside the security testing, the auditor checks conformity to the ABDM sandbox specifications, the NDHM Secure Application Development reference, FHIR R4 conformance at the security boundary, and the Health Data Management Policy 2020. This is what makes a WASA audit more than a generic VAPT.

• Client: Provide milestone approval evidence and API conformance details.
• CERT-In auditor (SICHERTEN): Map controls to ABDM and HDM requirements; record conformity metrics and gaps.

Deliverable: Compliance Checklist Report (CCR) summarising ABDM/HDM conformity.

Phase 5, Reporting (2–3 days)

Consolidate findings into the formal, decision-grade audit report

The auditor produces the report the applicant’s engineers will remediate against and that — in its final form — NHA will read. It is written to survive NHA scrutiny: prioritised, evidenced and specific.

• Contents: executive summary in business terms; scope and methodology; severity-ranked findings table (Critical / High / Medium / Low); per-finding detail with evidence, CVSS, affected endpoints, reproduction steps and concrete remediation guidance; ABDM/HDM compliance mapping; the tester’s conclusion.

• Client: Review the draft; convene the engineering owners for the findings walkthrough.
• CERT-In auditor (SICHERTEN): Deliver the draft WASA report; walk the client team through every Critical and High finding.

Deliverable: Draft Web Application Security Audit (WASA) Report.

Phase 6, Remediation support & revalidation (5–15 days (applicant-dependent))

Help close findings, then independently re-test to confirm closure

The applicant’s developers fix the findings; the auditor supports, then independently verifies. All Critical and High vulnerabilities must be closed before certification — non-negotiable. Medium and Low issues are either remediated or formally risk-accepted with justification. Re-submission after fixes is where most timelines slip; realistic planning assumes at least one remediation cycle.

• Client: Remediate findings; patch, reconfigure, redeploy; provide fix evidence.
• CERT-In auditor (SICHERTEN): Give prioritised remediation guidance; validate patches; run targeted retests and revalidation scans.

Deliverable: Vulnerability Closure Certificate (VCC) confirming all Critical and High findings remediated and revalidated.

Phase 7, Certification & Safe-to-Host issuance (1–2 days)

Issue the signed attestations the NHA requires

With a clean revalidation, the auditor issues the final certification package. The Safe-to-Host certificate is the artefact that unlocks the NHA submission — it states that the audited application (identified by URL and a build hash) has undergone VAPT, is free from known OWASP Top 10 vulnerabilities, and is safe for hosting as of the issuance date.

• Client: Freeze the audited build; ensure the submitted build matches the audited build exactly.
• CERT-In auditor (SICHERTEN): Sign and issue the final WASA Report, VCC and Safe-to-Host certificate under CERT-In empanelment.

Deliverable: Final WASA Report (signed) · Vulnerability Closure Certificate · Safe-to-Host Certificate.

What the manual testing phase actually covers

Automated scanning finds known CVEs, misconfiguration and TLS issues, breadth, not depth. Business-logic testing is what tools cannot understand, and exactly what NHA reviewers check for:

• OWASP Top 10 (2021). Injection (SQL, command, NoSQL), XSS, CSRF, broken authentication, sensitive-data exposure, XXE, broken access control, security misconfiguration, vulnerable components, insufficient logging.
• Authentication & session. Login security, brute-force and credential-stuffing resistance, session timeout, token binding and rotation, cookie flags, MFA where required.
• Authorization & access control. Horizontal and vertical privilege escalation — and the ABDM-critical case of cross-patient data access: can user A ever reach patient B’s ABHA-linked records?
• API security. Every endpoint touching ABDM services: authorization per method, rate limiting, mass assignment, IDOR on ABHA and consent identifiers, input validation, error-message leakage.
• Consent & data-flow integrity. Consent-artefact validation (expiry, scope, purpose enforcement); linking-token replay; can data be pulled or pushed outside a valid consent?
• Encryption. Data encrypted in transit (TLS version and configuration) and at rest; key handling; FHIR payload protection.
• Infrastructure & hardening. Server hardening, security headers, exposed services and ports, default credentials, verbose errors, directory listing.
• Logging & monitoring. Audit-trail completeness for health-record access — sufficient to reconstruct who accessed which ABHA-linked record, and when.

What the CERT-In auditor signs

Three artefacts close the engagement. Together they are what NHA reads.

Validity and change control. The Safe-to-Host certificate is valid for one year from issuance, provided no dynamic or material change is made to the audited application. A significant code or architecture change invalidates it and requires re-audit — plan your release calendar accordingly.

Who is responsible for what (RACI)

R Responsible · A Accountable · C Consulted · I Informed. “Auditor” means the CERT-In empanelled team.

Common failure modes, and how the process prevents them

Most delays are predictable. These are the ones we see most often:

Glossary

The acronyms you will meet across ABDM documentation:

Preparation checklist

Have these ready before Phase 1. They are, in our experience, the difference between an audit that runs to plan and one that stalls:

• All three milestones (M1/M2/M3) approved and functional testing report in hand, WASA is downstream of functional sign-off; auditing an unstable build wastes the window.
• Architecture and data-flow documentation, current as-built, Drives accurate scoping; stale docs cause missed attack surface.
• Sandbox credentials + test accounts for every user role, Access-control testing needs each role; missing roles mean an incomplete audit.
• Complete API collection (OpenAPI / Postman), Ensures every ABDM endpoint is in scope.
• A stable, frozen build for the audit window, Mid-audit deployments invalidate findings and force restarts.
• NDHM Secure Application Development reference — read and applied, Pre-empts entire finding classes; read at design time, not audit time.
• Named technical point of contact available during the window, Fast clarifications keep the engagement on schedule.
• Version-control discipline — audited build equals submitted build, Version mismatch between build and submission is a top NHA-rejection cause.

The bottom line

The biggest schedule risk in a WASA engagement is not the testing, it is remediation. Even a well-built application usually surfaces Critical or High findings on first assessment, and those must be closed and independently revalidated before certification. Applicants who treat security as an engineering priority from Milestone 1, rather than a checkbox before submission, certify materially faster and with far less drama.

If you are preparing for ABDM production access, our ABDM & ABHA Certification service covers the WASA audit end to end, scoping, testing, remediation support and the signed Safe-to-Host certificate.