ISECURION - CERT-In Empanelled Cybersecurity Firm
CERT-In Empanelled Firm ABDM Domain Experts Pan-India Coverage NHA Submission-Ready Reports Free Consultation
CERT-In
Formally Empanelled by CERT-In / MeitY
100%
NHA Report Acceptance Rate
2-4 Wks
Typical WASA Engagement Timeline
All India
Bangalore · Mumbai · Delhi · Hyderabad & More
Table of Contents
  1. What is ABDM M1 WASA Testing and Why It Is Mandatory
  2. Who Needs ABDM M1 WASA Testing
  3. Understanding the ABDM Milestone Framework
  4. Functional Testing vs Security Testing in WASA - What NHA Expects
  5. Complete ABDM M1 WASA Testing Scope and Checklist
  6. Deep Dive: ABHA Security and Identity Flow Testing
  7. Deep Dive: Consent Flow Security Testing
  8. ABDM API Security Testing - Common Vulnerabilities and Test Cases
  9. OWASP Top 10 for Digital Health Applications
  10. Common ABDM M1 WASA Failures and How to Avoid Them
  11. ABDM M1 WASA Audit Process - Step by Step
  12. How to Choose a CERT-In Empanelled ABDM WASA Auditor
  13. Frequently Asked Questions

1. What Is ABDM M1 WASA Testing and Why It Is Mandatory

India's healthcare system is undergoing the most significant digital transformation in its history. The Ayushman Bharat Digital Mission (ABDM), spearheaded by the National Health Authority (NHA), is building a nationwide integrated digital health infrastructure that allows patients to create a unique Ayushman Bharat Health Account (ABHA), link health records from multiple providers, and share those records securely with doctors, insurers, and other healthcare entities - all through a consent-based, interoperable digital ecosystem.

At the heart of this ecosystem is a rich API framework connecting Health Information Providers (HIPs), Health Information Users (HIUs), Health Lockers, and the ABDM gateway. Every digital health application seeking to participate in this ecosystem must integrate with these APIs - and that integration must be both functionally correct and security-hardened before it can access real patient data in the production environment.

This is where ABDM M1 WASA testing becomes critical.

WASA - Web Application Security Assessment - is the mandatory security and functional audit that NHA requires from all digital health applications before granting Milestone 1 (M1) certification. It must be conducted by a CERT-In empanelled auditor, and the resulting report must be submitted to NHA. Without a passing WASA report, no digital health application - regardless of how well-built or well-funded it is - can go live on the ABDM production environment.

Key Definition: ABDM M1 WASA (Web Application Security Assessment) is NHA's mandatory combined functional and security audit covering ABHA integration, consent flows, health record APIs, OWASP Top 10 vulnerabilities, authentication controls, data encryption, and API security - conducted by a CERT-In empanelled auditor on the ABDM sandbox environment before production access is granted.

The WASA requirement exists for a fundamentally important reason: health records contain the most sensitive personal data imaginable - diagnoses, prescriptions, mental health history, HIV status, genetic information. A security vulnerability in an ABDM-integrated application does not just expose business data; it exposes a patient's most private medical history. NHA's mandatory WASA audit is a critical safeguard ensuring that only applications meeting a defined security standard are permitted to handle this data at scale.

What makes ABDM WASA unique compared to a standard web application security assessment?

Unlike a generic web application security test, ABDM M1 WASA has a significant functional testing dimension. It is not sufficient for an application to simply be free of security vulnerabilities - it must also correctly implement every ABDM API flow. An application that implements ABHA linking incorrectly, or that handles consent artefacts improperly, will fail WASA even if it passes every security check. NHA requires both dimensions because a functionally incorrect implementation creates as much risk to patient data as a vulnerable one.

This dual nature - functional correctness plus security assurance - makes ABDM M1 WASA a specialized assessment that requires auditors with deep knowledge of both cybersecurity testing and the ABDM API specification. Generic penetration testers without ABDM domain expertise will produce incomplete reports that fail NHA review.

2. Who Needs ABDM M1 WASA Testing

Any organization building a digital health application that integrates with the ABDM ecosystem must complete M1 WASA testing before accessing NHA's production environment. There are no exemptions based on organization size, funding stage, or application complexity.

Health Information Providers (HIPs)

Hospitals, clinics, diagnostic labs, and pharmacies that generate and push patient health records to the ABDM network. HIP WASA scope includes record linking, care context management, and health document push APIs.

Health Information Users (HIUs)

Insurance companies, hospitals in consumer mode, and healthcare analytics platforms that request and consume patient health records through the ABDM consent architecture.

Health Locker Providers

Personal Health Record (PHR) applications that store patient health records linked to ABHA IDs. Health lockers sit at the centre of the consent ecosystem and face the widest WASA scope.

EHR / EMR Vendors

Electronic Health Record and Electronic Medical Record software vendors whose systems are being integrated with ABDM - either as standalone HIP integrations or as platforms serving multiple hospitals.

Telemedicine Platforms

Online consultation platforms that generate prescriptions, lab orders, and health records through consultations, and need to push these to ABDM as HIPs.

Pharmacy & Insurance Platforms

Digital pharmacy apps contributing prescription records, and health insurance platforms acting as HIUs to access policy-holder health records with consent.

An important nuance: if your organization plays multiple roles in the ABDM ecosystem (for example, a platform that acts as both HIP and HIU), the WASA scope must cover both role implementations. A hospital EHR that links records as a HIP and fetches records as an HIU for referrals needs both HIP and HIU test cases validated. Be explicit with your auditor about all roles your application plays in the ABDM ecosystem during the scoping phase.

3. Understanding the ABDM Milestone Framework

ABDM certification follows a milestone-based structure. Understanding where WASA fits within this framework helps organizations plan their compliance journey and allocation of resources effectively.

Milestone 1 (M1) - WASA and Production Access

M1 is the foundational gate. It requires successful completion of the WASA assessment covering functional correctness of ABDM API implementations and security hardening of the application. A CERT-In empanelled auditor conducts the assessment on the ABDM sandbox environment, produces an NHA-formatted report, and upon satisfactory remediation of critical findings, NHA grants M1 certification and production environment access. Without M1, no patient data can flow through the application on production.

Milestone 2 (M2) - Transaction Volume and Quality

Once live on production with M1 certification, NHA evaluates M2 based on the volume and quality of ABDM transactions processed - health records linked, consent flows completed, health data exchanges performed. Security foundations established at M1 directly enable smooth M2 progress because a well-secured implementation is less prone to API failures and data integrity issues.

Milestone 3 (M3) - Scale and Impact

M3 measures the broader impact of the organization's ABDM participation at scale - the number of patients served, the depth of health record interoperability achieved, and the contribution to the national health data ecosystem. Organizations that rush through M1 with minimum compliance often encounter compounding technical debt at M3 scale.

Planning Advice: Start your ABDM M1 WASA assessment at least 8-10 weeks before your target production go-live date. Allow 2-4 weeks for the assessment itself, plus 3-5 weeks for remediation of identified gaps and re-validation before NHA submission.

The ABDM Sandbox Environment and WASA

A critical operational requirement: ABDM M1 WASA testing is conducted on the ABDM sandbox environment - not on production. The sandbox replicates the production ABDM gateway, allowing realistic API testing without exposing real patient data. Your organization must have sandbox credentials, test ABHA IDs, and a functioning sandbox integration before WASA testing can commence. Engage your auditor early to confirm sandbox readiness - assessment timelines cannot begin until the sandbox environment is stable and testable.

4. Functional Testing vs Security Testing in WASA - What NHA Expects

One of the most important things to understand about ABDM M1 WASA testing is that it has two distinct and equally important dimensions: functional testing and security testing. Many organizations focus exclusively on security and are surprised when WASA findings include functional failures. NHA requires both because both types of failure create real-world risk to the patient data ecosystem.

Functional Testing - Correctness of ABDM Implementation

Verifies that every ABDM API flow works as NHA specifies:

  • ABHA creation and verification flows complete correctly
  • Care context discovery returns accurate patient records
  • Consent request, grant, and revoke flows follow the ABDM consent protocol
  • Health record fetch delivers correctly structured FHIR bundles
  • Health record push validates document type, format, and timestamps
  • Subscription and notification flows deliver events reliably
  • Error handling returns appropriate responses and codes
  • Edge cases (expired consent, partial data, network failures) handled gracefully
Security Testing - Protection of Patient Data

Verifies that the application and its ABDM integrations are secure against attack:

  • OWASP Top 10 vulnerability assessment of the application
  • ABHA OTP bypass and enumeration attempts
  • Consent artefact forgery and replay attack testing
  • API authentication and authorization bypass testing
  • IDOR (Insecure Direct Object Reference) on patient record APIs
  • FHIR injection and XML entity attack testing
  • TLS configuration and data encryption validation
  • Session management and token security review
  • Business logic abuse scenarios for consent and record access

The key insight for development teams is that fixing security vulnerabilities and fixing functional gaps require different skills and different timelines. Security vulnerabilities are often quicker to fix once identified - a missing rate limit, an unparameterized query, or an insecure header can be patched in days. Functional gaps - incorrect FHIR resource structures, missing consent artefact validation, or broken demographic matching - may require architectural changes that take weeks. Plan your pre-WASA remediation timeline accordingly, and share an early audit gap report with your development team as soon as possible.

5. Complete ABDM M1 WASA Testing Scope and Checklist

Use this checklist as a pre-WASA readiness assessment. Every item below is evaluated during a formal ABDM M1 WASA engagement.

1. ABHA ID Management Flows
  • ABHA creation via Aadhaar OTP and mobile OTP - functional validation and OTP security testing
  • ABHA address (username) creation, uniqueness validation, and format correctness
  • ABHA verification - PHR address resolution against ABDM gateway
  • ABHA profile retrieval - demographic data accuracy and completeness
  • ABHA linking at HIP - demographic matching correctness and anti-spoofing controls
  • ABHA deactivation / KYC flows where applicable

Security focus: OTP brute force, enumeration, ABHA number prediction, rate limiting absence

2. Consent Flow Implementation
  • HIU initiates consent request with correct purpose, date range, and Hi-types specified
  • Consent request delivered to patient's PHR application correctly
  • Patient grants consent - consent artefact generated, signed, and delivered to HIU
  • Patient revokes consent - consent artefact invalidated and health data access terminated
  • Consent expiry enforcement - data access denied after consent expiry
  • Purpose-based access control - Hi-types not covered by consent cannot be fetched
  • Multiple consent request handling - correct prioritization and artefact management

Security focus: Consent bypass, artefact replay, purpose scope violation, expired consent abuse

3. Health Record Fetch and Push APIs
  • HIU initiates health data request with valid consent artefact
  • HIP receives data request, validates consent artefact authenticity and scope
  • FHIR bundle construction - correct resource types, coding systems, and references
  • Data transfer encryption - health data encrypted in transit using ABDM-specified keys
  • Health record push - HIP pushes records correctly on patient data access events
  • Document type validation - DiagnosticReport, Prescription, OPConsultation, DischargeSummary, etc.
  • Data availability callback - HIP acknowledges data push with correct response codes

Security focus: Access without valid consent, FHIR injection, data integrity tampering, malformed payload handling

4. ABDM Gateway Authentication and Token Security
  • Client credential flow (OAuth 2.0) - correct implementation and token refresh
  • Access token scope validation - tokens cannot be used beyond granted permissions
  • Token expiry enforcement - expired tokens rejected by all API endpoints
  • Client secret storage - not hardcoded, not in logs, not in version control
  • ABDM gateway session management - session termination on logout
  • API key rotation procedures - documented and tested

Security focus: Token leakage in logs/responses, token replay, insecure secret storage, privilege escalation via scope manipulation

5. Data Encryption and Transmission Security
  • TLS 1.2 minimum enforced for all API endpoints - TLS 1.0/1.1 disabled
  • ABDM-specified end-to-end encryption for health data payloads
  • Certificate validity and trust chain correctness
  • Health data at rest - encrypted with appropriate key management
  • No sensitive data in URL parameters or query strings
  • Appropriate cache-control headers preventing sensitive data caching
  • Secure headers - HSTS, X-Frame-Options, CSP, X-Content-Type-Options
6. OWASP Top 10 Security Assessment
  • Injection (SQL, NoSQL, FHIR, XML) - parameterized queries and input validation
  • Broken authentication - MFA for administrative access, secure login controls
  • Sensitive data exposure - no PII/PHI in logs, error messages, or API responses
  • XML External Entity (XXE) attacks - FHIR XML parser hardening
  • Broken access control - IDOR on patient records, unauthorized API access
  • Security misconfiguration - directory listing, default credentials, debug mode
  • Cross-Site Scripting (XSS) - reflected and stored XSS in patient-facing interfaces
  • Insecure deserialization - object injection in API payloads
  • Using components with known vulnerabilities - dependency scanning
  • Insufficient logging and monitoring - audit trails for health data access
7. Mobile Application Security (Where Applicable)
  • ABHA SDK integration review - correct API usage and token handling
  • Local data storage - no sensitive health data in plaintext local storage
  • Certificate pinning - prevents MITM interception of ABDM API traffic
  • Deep link handling - ABHA deep links cannot be intercepted by malicious apps
  • Intent and IPC security - patient health data not leaked via Android intents
  • Reverse engineering resistance - appropriate code obfuscation applied
  • Keystore usage - sensitive keys stored in Android Keystore / iOS Secure Enclave

6. Deep Dive: ABHA Security and Identity Flow Testing

The Ayushman Bharat Health Account (ABHA) is the identity backbone of the entire ABDM ecosystem. Every interaction - record linking, consent, health data fetch - begins with ABHA verification. If ABHA flows are poorly implemented, the entire security model of the health data ecosystem breaks down. WASA auditors dedicate significant testing effort to ABHA security because it is the highest-risk component.

ABHA OTP Security

ABHA creation and verification use OTP-based authentication via Aadhaar or mobile number. WASA testing specifically evaluates whether these OTP flows are protected against abuse. Missing rate limits on OTP generation APIs allow an attacker to generate thousands of OTP requests - burning the victim's phone credit, locking their ABHA, or enabling enumeration of valid ABHA numbers. Missing rate limits on OTP verification allow brute-force attacks against 6-digit OTPs, which have only one million possible values. Both are tested during WASA.

ABHA Linking and Demographic Matching

When a HIP links a patient's existing health records to their ABHA ID, it performs demographic matching - comparing the patient's name, date of birth, and gender against ABHA records. This matching must be implemented correctly and securely. WASA testing evaluates whether the matching logic can be spoofed (by providing false demographics that match another patient's ABHA), whether partial matches are handled safely, and whether the linking process is protected against IDOR attacks that could link records to an attacker-controlled ABHA ID.

ABHA Discovery - Care Context Security

When a patient connects to a HIP using their ABHA address, the HIP returns a list of care contexts - past visits, reports, prescriptions associated with that patient. This discovery API is a significant privacy risk if implemented incorrectly. WASA testing checks whether care context discovery is limited strictly to the authenticated patient's records, whether it leaks any information about other patients sharing similar demographics, and whether the discovery API rate limits prevent patient record enumeration.

Token-Based Identity Assertions

All ABDM API calls use gateway-issued tokens to assert the identity of the calling entity. WASA auditors test whether these tokens are validated correctly - checking signature, expiry, issuer, and scope - and whether any endpoint accepts unsigned or expired tokens, accepts tokens issued to a different entity, or allows scope escalation through token manipulation.

8. ABDM API Security Testing - Common Vulnerabilities and Test Cases

The ABDM ecosystem is fundamentally API-driven. Every interaction between HIPs, HIUs, health lockers, and the ABDM gateway happens through REST APIs carrying FHIR-structured health data. API security is therefore the most technically intensive part of ABDM M1 WASA testing.

Insecure Direct Object Reference (IDOR) on Health Records

IDOR vulnerabilities in health record APIs allow an attacker to access records belonging to other patients by simply modifying a patient ID, record ID, or care context ID in an API request. WASA testing systematically evaluates every parameterized health record API endpoint for IDOR vulnerabilities. This is the single most common critical finding in ABDM WASA assessments - many development teams implement authentication correctly but forget to verify that the authenticated user is actually authorized to access the specific record being requested.

API Rate Limiting and Throttling

Health data APIs without rate limiting are vulnerable to bulk enumeration attacks - an attacker with valid credentials can scrape large volumes of health records in minutes. WASA testing verifies that rate limits exist on all sensitive endpoints (ABHA lookup, consent status, health record fetch), that these limits are enforced per user rather than per IP (to prevent easy bypass via IP rotation), and that rate limit responses do not leak sensitive information about the existence of records.

Mass Assignment in Health Record APIs

Mass assignment vulnerabilities allow an API consumer to set fields that should be server-controlled - for example, setting a health record's creation date, patient identity, or consent status through the API request body. In health applications, mass assignment can allow an attacker to forge health records with manipulated timestamps, incorrect patient associations, or fabricated clinical data. WASA testing submits API requests with unexpected fields and verifies that server-controlled fields cannot be overridden.

FHIR Resource Security

ABDM uses the FHIR (Fast Healthcare Interoperability Resources) standard for health data exchange. FHIR resources are XML or JSON structured documents that can be vulnerable to injection attacks if not parsed safely. WASA testing submits malformed FHIR payloads containing XML entity attacks (XXE), oversized payloads designed to cause denial of service, and resources with malicious embedded content in text fields. FHIR parsers must be configured to reject external entity declarations and to enforce size limits.

Subscription and Webhook Security

ABDM's subscription model allows HIPs and HIUs to register webhooks to receive event notifications. Webhooks are a known SSRF (Server-Side Request Forgery) attack vector - if an attacker can register a webhook pointing to an internal IP address, they can force the application server to make requests to internal services. WASA testing attempts to register SSRF payloads as webhook URLs and verifies that the application validates and allowlists webhook destinations before registration.

9. OWASP Top 10 for Digital Health Applications - What WASA Testing Covers

ABDM M1 WASA testing applies the OWASP Top 10 framework with healthcare-specific test cases reflecting the unique threat model of patient data applications.

OWASP Category Healthcare-Specific Application Key WASA Test Cases
A01: Broken Access Control Accessing another patient's health records; bypassing consent requirements; admin function access by regular users IDOR on patient records; consent bypass; horizontal and vertical privilege escalation; forced browsing of patient URLs
A02: Cryptographic Failures Health data transmitted in cleartext; passwords stored as MD5; sensitive data in application logs TLS validation; cipher suite review; log inspection for PHI/PII leakage; encryption of FHIR payloads at rest and in transit
A03: Injection SQL injection on patient search; FHIR/XML injection; NoSQL injection in document stores; OS command injection in report generators Parameterized query testing; FHIR payload fuzzing; XXE via FHIR XML; NoSQL operator injection on JSON APIs
A04: Insecure Design Architectural consent bypass; ABHA linking without demographic validation; record access without gateway token validation Threat model review; consent artefact validation bypass; demographic matching logic testing; token validation completeness
A05: Security Misconfiguration ABDM sandbox credentials leaked to production; debug mode enabled; directory listing on FHIR document storage Environment configuration review; HTTP method testing; security header audit; error message verbosity testing
A06: Vulnerable Components Outdated FHIR libraries with known CVEs; vulnerable JWT libraries; outdated ABHA SDK versions Dependency vulnerability scan; FHIR library CVE check; JWT library security testing; third-party component audit
A07: Auth and Session Failures ABHA OTP brute force; session tokens not invalidated on logout; weak JWT secrets OTP rate limiting; session fixation; JWT algorithm confusion attack; token invalidation on logout and password change
A08: Integrity Failures Health records modified in transit; FHIR document signatures not validated; auto-update mechanisms not secured FHIR signature validation testing; ABDM callback authenticity verification; supply chain assessment for ABHA SDK
A09: Logging Failures No audit trail for health record access; patient data in application logs; no alerting on consent abuse patterns Audit log completeness review; PHI/PII leakage in logs; log access control testing; monitoring coverage for ABDM events
A10: SSRF Webhook URL injection pointing to internal services; FHIR document URL fetch pointing to internal resources Webhook SSRF testing with RFC 1918 targets; FHIR reference URL injection; cloud metadata endpoint access via SSRF

10. Common ABDM M1 WASA Failures and How to Avoid Them

These are the most frequently observed failures across ABDM M1 WASA assessments. Understanding them before your assessment allows your team to remediate proactively.

Failure 1: Missing OTP Rate Limiting

ABHA OTP generation and verification APIs without rate limiting are among the most common critical findings. These endpoints allow brute-force attacks on 6-digit OTPs and mass OTP generation abuse. Implement rate limiting at both the application layer and API gateway, and add exponential backoff after repeated failures.

Failure 2: Incomplete Consent Artefact Validation

Many implementations check that a consent artefact exists but do not validate its signature, expiry, and scope completely. Revoked artefacts that continue to enable data access is a frequently found critical vulnerability. Implement full artefact validation on every health data request, not just on initial setup.

Failure 3: IDOR on Health Record APIs

Authentication checks at login and authorization checks at resource access are two different things. Many applications authenticate users correctly but fail to verify that an authenticated user is authorized to access the specific patient record they are requesting. Every health record API must verify record ownership or consent before returning data.

Failure 4: Sensitive Data in Application Logs

Development teams commonly log ABHA numbers, patient demographics, OTP values, and health record content during debugging. These logs are rarely sanitized before WASA. Review all logging configurations before the assessment and ensure no PHI or authentication credentials appear in application or server logs.

Failure 5: Incorrect FHIR Resource Structures

The functional testing dimension of WASA frequently reveals FHIR bundles with incorrect resource types, missing mandatory fields, invalid coding system references (SNOMED, LOINC, ICD-10), or incorrectly formatted timestamps. Validate all FHIR output against the ABDM FHIR Implementation Guide before the assessment using NHA's own validator tools.

Failure 6: Hardcoded Sandbox Credentials in Code

ABDM sandbox client IDs, client secrets, and gateway URLs are commonly hardcoded in application code during development - and often forgotten there. WASA auditors review code configuration files and environment settings for hardcoded credentials. Use environment variables and a secrets management solution for all ABDM credentials.

Failure 7: Missing Security Headers

Patient-facing interfaces for health locker and PHR applications frequently lack standard security headers - HSTS, Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options. These headers prevent significant classes of client-side attacks including clickjacking and MIME-type confusion. They are quick to implement and should be added as part of production configuration.

Failure 8: Untested Error Handling and Edge Cases

Functional testing reveals that applications frequently do not handle ABDM API error responses gracefully. Expired tokens, gateway timeouts, invalid ABHA addresses, and consent revocation mid-session must all be handled with appropriate error flows. Verbose error messages returning stack traces or internal data structures fail both functional and security dimensions of WASA.

11. ABDM M1 WASA Audit Process - Step by Step

Understanding the full WASA engagement process helps your team set realistic timelines, prepare effectively, and avoid last-minute surprises before NHA submission.

1
Initial Scoping and NDA

Kickoff with your auditor to confirm entity type (HIP/HIU/Health Locker), ABDM API inventory, tech stack, and target sandbox environment. Execution of NDA protecting your application code and test data. Confirm ABDM sandbox credentials are provisioned and test ABHA IDs are ready.

2
ABDM API and Architecture Review

Review of ABDM API integration code, FHIR implementation, consent flow architecture, and data flow diagrams against NHA specifications. Identification of design-level gaps before active testing begins - catching architectural issues early saves significant remediation time.

3
Functional Testing - All ABDM Flows

Systematic execution of all ABDM functional test cases covering ABHA creation, linking, consent flows, health record fetch/push, subscription, and error handling. Test cases are mapped to NHA's M1 requirements checklist and evidence captured for each.

4
Security Testing - OWASP and ABDM-Specific

OWASP Top 10 testing of the web application and any mobile components, ABDM-specific API security tests (IDOR, auth bypass, consent manipulation, FHIR injection, SSRF via webhooks), encryption validation, and authentication/session testing.

5
Interim Gap Report and Remediation Support

Delivery of an interim report with all identified functional gaps and security vulnerabilities, categorized by severity with CVSS scores. Auditor provides developer-level remediation guidance and supports clarification calls with your engineering team to minimize ambiguity during the fix cycle.

6
Re-Testing and Closure Verification

Re-testing of all remediated findings to confirm effective fixes that have not introduced new vulnerabilities. Issuance of a formal closure letter for each remediated finding - a required component of the NHA WASA submission package.

7
WASA Audit Report and NHA Submission Pack

Delivery of the complete NHA-formatted WASA audit report, functional test evidence pack, security vulnerability report, closure letter, and NHA submission documentation - all signed by a CERT-In empanelled auditor and ready for direct submission to NHA for M1 certification.

12. How to Choose a CERT-In Empanelled ABDM WASA Auditor

Not all CERT-In empanelled firms have the ABDM domain expertise to conduct a WASA assessment that NHA will accept without queries. Use this evaluation framework when selecting your audit partner.

Verify Active CERT-In Empanelment

NHA accepts WASA reports only from currently empanelled CERT-In auditors. Verify at cert-in.org.in before engagement.

  • Confirm the firm's name appears on the current CERT-In empanelled auditors list
  • Check that the empanelment is active - not expired - at the time of your engagement
  • Verify the scope of empanelment covers web application security assessments
  • Request a copy of the current empanelment certificate and cross-verify with the CERT-In list

Watch out for: Firms claiming to be "associated with" an empanelled auditor. Only direct empanelment is accepted.

Confirm ABDM-Specific Domain Expertise

Generic web security testers without ABDM knowledge cannot correctly evaluate functional API correctness, FHIR resource validity, or consent artefact security.

  • Ask how many ABDM M1 WASA assessments the firm has completed
  • Confirm auditors have hands-on experience with ABDM API specifications and FHIR
  • Verify familiarity with NHA's M1 functional testing checklist requirements
  • Request a sample WASA scope document showing ABDM-specific test cases

Watch out for: Auditors who cannot explain the difference between HIP and HIU WASA scope, or who propose a standard OWASP web test without any ABDM-specific functional testing.

Confirm Integrated Functional + Security Testing
  • Verify the auditor covers both dimensions - functional correctness AND security testing - in one engagement
  • Confirm VAPT (Vulnerability Assessment and Penetration Testing) is included in scope
  • Ask how functional test evidence is integrated into the WASA audit report
  • Ensure mobile application testing is included if your application has an Android/iOS component
Evaluate Deliverables and NHA Report Format
  • WASA audit report formatted to NHA requirements and signed by CERT-In empanelled auditor
  • Functional test evidence pack - API request/response logs and test case pass/fail mapped to NHA checklist
  • Security vulnerability report - findings with CVSS ratings and remediation guidance
  • Closure letter - formal re-test confirmation for remediated findings (required by NHA)
  • NHA submission pack - all documents bundled and ready for direct NHA submission
Confirm Timeline Commitments and Remediation Support
  • Verify the auditor can commit to your production go-live timeline with binding milestone dates
  • Confirm they provide developer-level remediation guidance - not just a vulnerability list
  • Ask whether re-testing for remediated findings is included or charged separately
  • Confirm sandbox environment readiness requirements and any blocking dependencies

ISECURION - Your CERT-In Empanelled ABDM M1 WASA Testing Partner Across India

ISECURION is formally CERT-In empanelled, ISO 27001:2022 certified, and specializes in ABDM M1 WASA testing for HIPs, HIUs, health lockers, EHR vendors, telemedicine platforms, and all digital health application developers seeking NHA M1 certification. Our reports are submission-ready for NHA - no guesswork, no rework.

Bangalore Mumbai Delhi NCR Hyderabad Chennai Kolkata Pan-India
Learn About Our ABDM WASA Service Get Free Consultation +91-88612 01570

Frequently Asked Questions - ABDM M1 WASA Testing

Common questions from digital health developers, HIPs, HIUs, and healthcare platform teams across India about ABDM M1 WASA requirements and the assessment process.

ABDM M1 WASA (Web Application Security Assessment) is the mandatory combined functional and security audit that the National Health Authority (NHA) requires for all digital health applications before granting Milestone 1 (M1) certification and production environment access. It evaluates two dimensions simultaneously: functional correctness of ABDM API implementations (ABHA creation, linking, consent flows, health record fetch/push, FHIR validation) and security hardening of the application (OWASP Top 10, API security, consent bypass prevention, data encryption, authentication controls). Both dimensions must pass for NHA to accept the WASA report.

Yes, ABDM M1 WASA testing is a mandatory hard gate. No digital health application - regardless of how technically well-built it is, how well-funded the organization is, or what other certifications it holds - can access the ABDM production environment without submitting a passing WASA report from a CERT-In empanelled auditor to NHA. Applications that attempt to bypass this requirement or use non-empanelled auditors have their reports rejected by NHA, delaying production access indefinitely.

For a standard application with a well-implemented ABDM integration, the assessment phase takes approximately 2-4 weeks - covering scoping, functional testing, security testing, and draft report delivery. After the draft report, allow an additional 3-5 weeks for remediation of identified gaps, re-testing, and issuance of the final WASA report with closure documentation for NHA submission. Total timeline from kickoff to NHA submission is typically 5-8 weeks. Complex platforms with multiple ABDM roles or significant implementation gaps may require longer. Engage your auditor early - do not start the WASA assessment less than 8 weeks before your target go-live date.

No. NHA mandates that WASA reports be produced by CERT-In empanelled auditors. Reports from non-empanelled providers - regardless of the provider's technical reputation, certifications, or market standing - are not accepted by NHA for M1 certification. This requirement is non-negotiable. Before engaging any security firm for ABDM WASA, verify their empanelment status directly at cert-in.org.in. Also be cautious of firms claiming to be "affiliated with" or "partnered with" an empanelled organization - only the firm that directly holds CERT-In empanelment is authorized to sign and submit WASA reports to NHA.

ABDM M1 WASA testing is conducted on the ABDM sandbox environment, as mandated by NHA. The sandbox replicates the ABDM production gateway API behaviour, allowing realistic functional and security testing without exposing real patient data. Your organization must have active sandbox credentials, test ABHA IDs, and a stable sandbox integration before testing can commence. Only after the WASA assessment passes on sandbox, NHA reviews the report, and grants M1 certification, can your application access the ABDM production environment and interact with real patient data.

The most frequently observed WASA failures include: (1) Missing OTP rate limiting on ABHA creation and verification APIs; (2) Incomplete consent artefact validation - particularly missing revocation checks; (3) IDOR vulnerabilities on health record APIs allowing access to other patients' data; (4) Sensitive data (ABHA numbers, OTP values, health records) appearing in application logs; (5) Incorrect FHIR resource structures failing NHA's functional requirements; (6) Hardcoded sandbox credentials left in production code; (7) Missing TLS or weak cipher configuration; (8) Absent or incomplete security headers on patient-facing interfaces. Starting with a pre-WASA gap assessment allows your team to remediate these issues before the formal assessment begins.

Yes, the WASA scope varies significantly based on your ABDM role. HIPs (Health Information Providers) are assessed on ABHA linking, care context management, health record push APIs, and care context discovery. HIUs (Health Information Users) are assessed on consent request creation, consent artefact handling, health record fetch APIs, and data handling post-fetch. Health Lockers face the broadest scope - both HIP and HIU flows plus the patient consent management UI, ABHA profile management, and health record storage security. If your application plays multiple roles, all applicable role scopes are assessed. Be explicit with your auditor about every ABDM role your application implements during the initial scoping phase.

Yes. ISECURION provides ABDM M1 WASA testing services across India - Bangalore, Mumbai, Delhi NCR, Hyderabad, Chennai, Kolkata, Pune, and all cities - through both on-site and remote testing engagement models. With offices in Bangalore and Kolkata, we serve digital health startups, hospitals, EHR vendors, telemedicine platforms, and insurance health platforms of all sizes across India. Contact us at info@isecurion.com or call +91-88612 01570 to begin the scoping conversation.

Extend your digital health security posture beyond ABDM M1 WASA with these related resources.

Web Application Security Assessment

Comprehensive OWASP-based web application security testing for healthcare portals and patient-facing platforms beyond ABDM scope.

Learn more →

Mobile Application Security Testing

Security testing of ABDM-integrated Android and iOS apps - ABHA SDK review, deep link security, local storage, and certificate pinning.

Learn more →

DPDP Act Compliance

India's Digital Personal Data Protection Act compliance for digital health platforms handling patient personal data alongside ABDM obligations.

Learn more →

ISO 27001 Certification

Build a certified ISMS for your healthcare organization - complements ABDM WASA controls and supports NABH requirements.

Learn more →

Cloud Security Assessment

Security assessment of AWS, Azure, or GCP environments hosting ABDM-integrated health applications and patient data.

Learn more →

ABDM M1 WASA Testing Service

Our dedicated ABDM M1 WASA testing service page - complete scope, methodology, deliverables, and how to engage ISECURION.

View service →

Ready to Start Your ABDM M1 WASA Assessment?

ISECURION's CERT-In empanelled team delivers end-to-end ABDM M1 WASA testing - functional testing, OWASP security, ABHA and consent flow security, NHA-ready reports - across Bangalore, Mumbai, Delhi, Hyderabad, Chennai, Kolkata, Pune, and all of India.

Get WASA Testing Quote Schedule Free Consultation +91-88612 01570
CERT-In Empanelled ABDM Domain Experts NHA Submission-Ready ISO 27001:2022 Certified
ABDM M1 WASA Testing Services Across India: ISECURION provides CERT-In empanelled ABDM M1 WASA testing (Web Application Security Assessment) in Bangalore, Mumbai, Delhi, Hyderabad, Chennai, Kolkata, Pune, and all major Indian cities. We serve HIPs, HIUs, health locker providers, hospitals, diagnostic labs, telemedicine platforms, EHR/EMR vendors, pharmacy apps, and all digital health application developers seeking ABDM M1 certification from NHA. Our ABDM WASA testing covers ABHA ID security testing, consent flow testing, health record fetch/push API security, FHIR resource validation, OWASP Top 10, API authentication, data encryption validation, and mobile app security. Keywords: ABDM M1 WASA testing India | ABDM WASA checklist | ABDM M1 functional testing | NHA ABDM compliance audit | ABDM ABHA security testing | ABDM consent flow security | ABDM API VAPT | ABDM FHIR security | CERT-In empanelled ABDM auditor | ABDM M1 testing company Bangalore | ABDM M1 WASA testing Mumbai | ABDM milestone 1 certification guide
WhatsApp - ABDM WASA Testing Enquiry