Author: Akhila A P

Zero Trust for Insurance: A 4-Level IRDAI Compliance Framework (2026)

On April 6, 2026, IRDAI notified revised information and cybersecurity guidelines that apply to every insurer, reinsurer, intermediary, and TPA operating in India. The guidelines mandate board-level oversight, an independent CISO reporting line, 6-hour breach notification to IRDAI and CERT-In, 180-day log retention, and comprehensive vendor risk management. Penalties for failure to implement reasonable security safeguards reach ₹250 crore under the DPDP Act.

For a life insurer with 8 million policyholders and 14 regional offices, this is not a checkbox exercise. It is a rearchitecting problem.

What Changed in April 2026

IRDAI’s April 2026 guidelines replace the 2023 circular and introduce three structural requirements that most insurers cannot satisfy with their current architecture.

The 6-hour breach notification requirement is the most operationally demanding. To notify CERT-In within 6 hours, you must detect the breach within roughly 4 hours, which means your SIEM must have ingested and correlated the relevant logs before the incident was confirmed. Most insurers in India run SIEM with 24 to 48-hour log ingestion delays from branch systems. That architecture cannot meet a 6-hour clock.

The independent CISO requirement specifying that the CISO shall not report to the Head of IT forces an organizational change that triggers an architecture review. CISOs who previously lived inside the IT cost center now have board visibility and procurement authority. The security controls they could not justify previously are now their mandate.

The vendor risk management requirement extends security obligations upstream. Before engaging any vendor with access to policyholder data, insurers must conduct cybersecurity due diligence and confirm compliance with IRDAI guidelines. This covers cloud providers, TPAs, broking platforms, and health data aggregators.

Why Zero Trust Is the Right Response

Traditional perimeter security cannot satisfy these requirements. Perimeter security assumes that traffic inside the network is trusted. Modern insurance environments have no meaningful perimeter: branch offices connect over public internet, TPAs access policy systems from their own networks, and cloud-hosted customer portals interact with on-premise policy administration systems.

Zero trust security assumes that no traffic, user, or device is trusted by default, regardless of network location. Every access request is authenticated, authorized against policy, and logged. This architecture produces the continuous monitoring and log completeness that IRDAI’s 6-hour notification requirement demands.

IRDAI’s 6-hour breach notification requirement is not a reporting problem it is a detection architecture problem. Zero trust solves the detection problem.

The Insurance Zero Trust Implementation Ladder (IZTIL)

IZTIL is a four-level maturity model for Indian insurers implementing zero trust against the April 2026 guidelines. Each level is a stable operating state, not a transition phase. An insurer can operate at Level 2 and meet most of the mandatory controls. Level 4 is the target for insurers with more than 5 million policyholders or significant digital distribution channels.

Level 1: Data Classification and Identity Foundation

No zero trust implementation can start without knowing where personal data lives. An insurer that cannot identify which systems hold personal data cannot implement zero trust. The data classification comes before the network segmentation.

At Level 1: classify all data stores by sensitivity (policyholder PII, health data, financial data, claims records); deploy identity provider with MFA enforced on all privileged accounts; disable shared service accounts and replace with machine identities; complete an asset inventory covering on-premise systems, cloud workloads, and third-party integrations.

Completion criterion: every system with personal data is tagged, owned, and accessible only via individual authenticated identities.

Level 2: Microsegmentation and SIEM Baseline

At Level 2: implement network microsegmentation between personal-data systems and general administrative networks; deploy SIEM with log ingestion from all systems hosting personal data at under 2-hour latency; establish 180-day log retention with immutable storage; and configure alerting thresholds for anomalous access patterns (off-hours access to claims systems, bulk record downloads, and new device access to underwriting systems).

This is the minimum level at which an insurer can credibly meet the 6-hour notification requirement. It is achievable in 4 to 6 months for a mid-sized insurer with a dedicated security engineering team.

Level 3: Continuous Verification and Vendor Governance

At Level 3: implement device posture checks on all endpoint access to policyholder systems; deploy privileged access management (PAM) with session recording for all administrative access; implement vendor risk assessment workflow covering IRDAI compliance confirmation, security questionnaire, and annual audit rights; extend SIEM ingestion to vendor-operated systems accessing insurer data.

The vendor governance component is frequently underestimated. Most mid-tier Indian insurers work with 40 to 80 vendors with some form of data access. Conducting due diligence across that vendor population takes 3 to 5 months even with automation.

Level 4: Adaptive Access and Automated Response

At Level 4: implement risk-based adaptive access policies that adjust authentication requirements in real time based on user behavior, device posture, and data sensitivity; deploy automated incident response playbooks for common breach scenarios (ransomware containment, credential compromise, and unauthorized data export); and integrate security telemetry with the board-level Cybersecurity Committee reporting dashboard.

Level 4 is where zero trust becomes a genuine business capability rather than a compliance posture.

The Legacy Policy Administration System Problem

Most insurers treat their legacy policy administration system as untouchable. Zero trust architecture disagrees.

The policy administration system (PAS) in most Indian life insurers is an on-premise Oracle or custom-built system running on hardware that is 8 to 15 years old. It holds the most sensitive data in the enterprise every policyholder record, every claim, every beneficiary designation. It also has the weakest security controls: broad shared database credentials, no MFA, minimal audit logging.

IZTIL Level 2 does not require replacing the PAS. It requires wrapping it. Deploy an API gateway between the PAS and all consuming systems. Enforce authentication at the gateway layer. Log all PAS access through the SIEM via the gateway. Implement network segmentation that blocks direct database access from outside the PAS VLAN.

This is less elegant than a modern microservices architecture, but it is achievable in 8 to 12 weeks without touching the PAS codebase. Attempting a full PAS modernization as part of a zero trust project doubles the risk and adds 18 to 24 months to the timeline. Separate the concerns.

DPDP Act Interaction: What Changes in May 2027

The DPDP Rules notified in November 2025 bring substantive compliance requirements into effect in May 2027. For insurers, the relevant obligations compound the IRDAI guidelines: consent for processing health data, data localization requirements for personal data stored in cloud, right-to-erasure workflows for lapsed policyholders.

The zero trust data classification work done under IZTIL Level 1 directly accelerates DPDP compliance. An insurer that has tagged every personal data store, assigned ownership, and inventoried all data flows is 60 to 70 percent of the way to DPDP readiness. Run both programs under the same data governance team.

What This Means for Insurance Leaders

The April 2026 guidelines give the CISO organizational authority that was previously unavailable. Use it now. The three decisions with the highest compliance leverage in the next 90 days are: deploy MFA on all privileged accounts (days 1 to 14, no architecture change required), standing up SIEM with 2-hour log ingestion from PAS and customer data systems (weeks 4 to 8), and completing vendor data access inventory (weeks 6 to 12).

These three steps get you to IZTIL Level 2 and put you in a defensible position for IRDAI examination. Everything else, like microsegmentation, PAM, and adaptive access, can follow in priority sequence. Do not attempt all four levels simultaneously. The implementation risk of a big-bang security rearchitecture in a regulated insurer exceeds the compliance risk of a phased approach.

More Blog: AIS 189 Compliance: What Automotive Engineers Must Do Now

Automotive CI/CD Is a Different Engineering Discipline. Build It That Way.

The engineering teams building this software need an Automotive CI/CD platform that does not exist in a standard DevOps toolkit. A software-defined vehicle runs on 100 to 150 million lines of code. It must satisfy functional safety standards (ISO 26262), cybersecurity requirements (ISO 21434, AIS 189 in India), and regulatory type approval while shipping OTA updates to vehicles in the field every 6 to 8 weeks. The engineering teams building this software need a CI/CD platform that does not exist in a standard DevOps toolkit.

An automotive engineering services firm in Pune managing embedded software delivery for a German OEM’s body control and ADAS module programs learned this the hard way. Their initial approach adapting a Jenkins and GitHub Actions pipeline from a prior cloud software project collapsed at the hardware-in-the-loop testing stage. Build validation times ran 14 hours. Safety certification traceability was manual. OTA staging had no rollback automation.

The problem was not their engineers. The problem was a web DevOps mental model applied to an automotive software problem.

Why Standard DevOps Fails in SDV Programs

SDV development has three properties that break standard web DevOps toolchains.

Safety lifecycle integration. ISO 26262 requires traceable links from system requirements through software design, implementation, unit test, integration test, and verification for every safety-critical function. This traceability cannot be an after-the-fact audit activity it must be captured as part of the build pipeline. Standard CI tools have no native concept of functional safety classification or ASIL (Automotive Safety Integrity Level) tagging.

Compilation and build complexity. An ECU software stack built on Classic AUTOSAR or Adaptive AUTOSAR compiles against hardware-specific tool chains (usually from Vector, ETAS, or Green Hills Software). These tool chains are not containerized, are often Windows-only, require hardware dongles for licensing, and take 30 to 90 minutes per full rebuild. Treating them like a Node.js or Python build system produces pipelines with 8 to 14-hour cycle times.

Hardware-in-the-loop (HIL) testing. Software validation in automotive requires running code on physical hardware rigs or certified simulation environments. HIL rigs cannot be spun up on demand like cloud VMs. They are physical assets, expensive to procure, and shared across teams. Managing HIL rig scheduling, utilization, and queuing is a platform engineering problem as important as the CI pipeline itself.

Automotive CI/CD is not web CI/CD with ISO 26262 annotations added at the end. The safety lifecycle has to be embedded in the pipeline, not bolted onto it.

Automotive CI/CD Maturity Model (SDMS)

SDMS is a five-level maturity model for automotive software CI/CD programs. Each level adds a specific capability that the previous level’s infrastructure supports. Moving from Level 1 to Level 5 typically takes 18 to 30 months for a program with 30 to 100 embedded software engineers.

Level 1: Version Control and Build Reproducibility

Automotive CI/CD enables automated safety traceability, OTA package creation, and rollback validation. Every software component lives in a version control system (Git with large-file storage for binary artifacts). Every build is reproducible from a pinned toolchain version and dependency lockfile. AUTOSAR tool chain versions are managed as team assets, not as individual developer installations.

Many automotive programs in India are still at this level or below. Individual engineers maintain tool chain installations on local Windows machines. Build reproducibility depends on which machine the build ran on. This is not a DevOps problem it is a configuration management problem that blocks all subsequent automation.

Level 2: Automated Build and Static Analysis

At this stage, Automotive CI/CD automates builds, static analysis, and artifact management for safety-critical software. At Level 2: automated builds trigger on every commit; static analysis tools (MISRA C compliance, Polyspace, QAC) run in the build pipeline against every changed component; build artifacts are stored in a binary artifact repository (Artifactory or Nexus) with ASIL classification tags.

The safety classification tagging at Level 2 is the investment that pays dividends at Level 4 and 5. Teams that skip it discover at certification time that they cannot produce the required tool qualification evidence for their CI system. Add it now.

Level 3: HIL Scheduling and Software-in-the-Loop Integration

At Level 3: software-in-the-loop (SIL) testing runs automatically in the CI pipeline using simulation environments (dSPACE HIL simulators, MATLAB/Simulink test automation, or CARLA for ADAS); HIL rigs are inventory-managed with a rig scheduling system that queues test jobs and reports utilization; test results flow into a test management system (qTest, TestRail, or custom) with links to requirements.

The build time problem in automotive is not a Jenkins configuration problem. It is a hardware-in-the-loop test farm scaling problem. Level 3 forces the program to treat HIL rigs as shared infrastructure with SLA commitments, not as lab equipment that someone books via email.

Level 4: Safety Traceability Automation and OTA Pipeline

At Level 4: requirements traceability is automated CI pipeline links every build artifact to the requirements it covers, the tests that verified it, and the ASIL level it satisfies; OTA update packages are generated, signed, and staged automatically from successful CI builds; rollback capability is tested as part of every OTA pipeline execution.

An OEM that cannot do OTA rollback in under 15 minutes does not have a software-defined vehicle program it has a very expensive field-service liability. Level 4 makes rollback a tested, documented capability, not an emergency procedure.

Level 5: Continuous Deployment to Vehicles and Telemetry Loop

At Level 5: validated updates flow automatically to a shadow fleet of instrumented test vehicles; vehicle telemetry feeds back into the CI system, triggering regression builds when anomalous behavior patterns are detected in the field; deployment ring management (alpha vehicles, beta fleet, general release) is automated with automatic hold triggers based on error rate thresholds.

Level 5 is the operational definition of software-defined. Most programs reach it at month 24 to 30 of a sustained SDMS improvement program.

The Adaptive AUTOSAR Transition Makes This Urgent

Classic AUTOSAR the dominant ECU software architecture for the past 15 years runs on microcontrollers with fixed scheduling and no operating system abstraction. Adaptive AUTOSAR, introduced for high-compute ADAS and infotainment domains, runs on Linux/QNX with a service-oriented architecture, dynamic service discovery, and containerized components.

The DevOps implications are significant. Adaptive AUTOSAR components can be containerized, which means they can be built and tested in standard CI infrastructure, not just on proprietary hardware-specific tool chains. This is the architectural change that makes automotive CI/CD tractable with modern DevOps tooling.

Programs still on Classic AUTOSAR should plan the SDMS progression as described above. Programs migrating to Adaptive AUTOSAR have an opportunity to build the CI infrastructure on a more modern foundation but they still need HIL rig management and safety traceability; the architecture change does not eliminate those requirements.

India’s SDV Engineering Opportunity

India has the strongest embedded software engineering pool for SDV outside of Germany. Tata Elxsi, Tata Technologies (with the recent WHIS partnership), and Tech Mahindra are building SDV engineering practices that compete with traditional Tier-1 suppliers. The constraint is not engineering talent it is DevOps tooling maturity.

Programs that build SDMS Level 3 and 4 capabilities now will win the SDV outsourcing contracts that are moving out of German and Japanese OEM in-house teams over the next 3 years. OEMs evaluating Indian engineering services partners will audit CI/CD maturity as a qualification criterion before awarding embedded software programs.

The SDV Summit in Bangalore this October will be the most important automotive engineering event in India in 2026. The firms presenting SDV DevOps capabilities at Level 4 or above will win the conversations that follow.

What This Means for Automotive Engineering Leaders

If you are running an embedded software program whether inside an OEM or as an Tier-1 or Tier-2 engineering services supplier assess your current SDMS level before committing to new program bids. The assessment takes one day and produces a concrete gap list.

Three decisions to make this month: identify your current tool chain installation management practice and determine whether it can support Level 1 reproducible builds; confirm whether your HIL rigs are scheduled via a management system or via ad hoc team coordination; and determine whether your OTA pipeline has automated rollback tested on a representative vehicle configuration.

If any of the three answers are “no” or “we don’t have that,” your program has SDMS Level 1 or 2 gaps. Closing them before the next OEM program review is worth more than any tooling investment you make elsewhere.

More Blog: Bima Sugam Phase 2 (2026): 7 Best Modernization Steps

Introduction

IoT Remote Patient Monitoring ABDM Integration India is becoming one of the biggest engineering challenges in India’s digital healthcare ecosystem. As hospitals and healthcare providers adopt wearable medical devices, successful integration with the Ayushman Bharat Digital Mission (ABDM) requires FHIR-compliant data exchange, ABHA linkage, secure consent management, and scalable middleware architecture.

A district hospital network in Karnataka managing 340 community health centers deployed 1,200 wearable ECG patches for a rural cardiac monitoring program. IoT Remote Patient Monitoring ABDM Integration India enables healthcare providers to securely connect wearable medical devices with ABHA-linked patient records using FHIR-compliant data exchange.

The devices worked. The network failed. This is the pattern Codelynks sees across nearly every hospital-grade IoT deployment in India that predates the ABDM Phase 2 roadmap. As ABDM pushes deeper into IoT and wearable integration this year, the middleware gap is becoming the primary blocker.

ABDM IoT Integration Requirements for Healthcare IoT Systems0

ABDM’s second phase has four stated integration priorities: deeper private-sector HIP and HIU onboarding, cloud-first data sharing, AI-enabled patient matching, and structured wearable and IoT device data flowing into longitudinal ABHA records. The last point is the one most hospital IT teams are unprepared for.

A wearable device connects to a patient who has an ABHA ID. The data from that wearable must satisfy four conditions: converted to FHIR R4 resource profiles (Observation, DiagnosticReport, DeviceMetric) aligned with NHA’s published Implementation Guides; linked to the patient’s ABHA ID via the Health Repository; subject to an active consent artifact approved by the patient through an ABDM-registered consent manager; and structured so that any authorized HIU can query and render the data without calling the device vendor’s proprietary portal.

None of this is impossible. None of it is handled by device vendors out of the box. Every IoT Remote Patient Monitoring ABDM Integration India deployment should support interoperability, consent management, and standardized healthcare data exchange across ABDM-compliant systems.

The Three Protocol Gaps That Kill RPM Deployments

Remote patient monitoring deployments fail at three distinct technical layers.

Protocol conversion. Consumer wearables use Bluetooth Low Energy with GATT profiles that were not designed for clinical data exchange. Medical-grade wearables often use proprietary radio protocols with vendor-specific data schemas. Neither maps to FHIR natively. The gap is bridged by an edge gateway: a device that collects raw sensor data, applies unit conversion and clinical coding (LOINC, SNOMED-CT), and structures the output as FHIR observations. Most hospital IoT deployments skip this layer and push raw data to the cloud vendor’s proprietary storage.

Connectivity. Karnataka’s district hospital network covers 340 CHCs across three districts. Roughly 230 of those CHCs have unreliable cellular coverage. NB-IoT provides better indoor penetration and lower power consumption than LTE-M but requires SIM provisioning with an NB-IoT-enabled operator. A deployment that assumes LTE-M and then discovers NB-IoT is needed mid-deployment adds 4 to 6 weeks to the integration timeline.

Consent lifecycle. A wearable that generates data every 15 seconds but pushes it to your EHR every 24 hours is not a remote monitoring solution. It is a very expensive logger. Real-time alert logic the clinical value of an RPM deployment requires continuous data flow. ABDM’s consent architecture requires an active, in-scope consent for each HIU data pull. Consent expiry (typically 180 days) is not notifi

Successful IoT Remote Patient Monitoring ABDM Integration India projects require protocol conversion, resilient connectivity, and automated consent lifecycle management. ed to the clinical system; it is the operator’s responsibility to track and renew. Manual handling at 1,200-device scale fails.

Healthcare organizations planning IoT Remote Patient Monitoring ABDM Integration India initiatives should perform a technical readiness assessment before deploying wearable devices.

ABDM IoT Integration Readiness Assessment Framework

Codelynks assesses hospital IoT deployments against five dimensions before recommending architecture decisions.

Dimension 1: Device protocol coverage. Does the deployment include devices from more than one manufacturer? Is there a protocol translation layer? Score: 0 (no translation layer), 1 (proprietary middleware), 2 (FHIR-native edge gateway).

Dimension 2: ABDM HIP registration. Is the hospital or device vendor registered as a Health Information Provider with NHA? Score: 0 (not registered), 1 (registration in progress), 2 (active, verified registration).

Dimension 3: Consent architecture. Does the system track consent lifecycle for each patient-device pair? Score: 0 (no consent tracking), 1 (manual tracking), 2 (automated consent state machine with proactive renewal).

Dimension 4: FHIR profile compliance. Does the system produce FHIR R4 output using NHA’s published implementation guide profiles or custom extensions? Score: 0 (proprietary format), 1 (generic FHIR without NHA profiles), 2 (NHA-compliant FHIR).

Dimension 5: Connectivity resilience. Does the edge layer handle intermittent connectivity with store-and-forward capability? Score: 0 (no offline tolerance), 1 (manual retry), 2 (automated store-and-forward with conflict resolution).

Total AIIRS score: 0 to 10. A score below 6 indicates the deployment cannot support real-time clinical decision-making. The Karnataka network scored 3 on the first assessment. After Codelynks redesigned the middleware layer, it scored 9.

Building an ABDM IoT Integration Middleware Architecture

The gap between a Bluetooth ECG patch and an ABHA-linked cardiac event record is not a hardware problem. It is a middleware problem. The architecture has four components.

An edge gateway deployed at the CHC level. In the Karnataka deployment, Codelynks used lightweight ARM-based edge nodes running a containerized FHIR conversion service. The gateway collects raw BLE data from ECG patches, applies LOINC coding (LOINC 11524-6 for ECG, LOINC 8867-4 for heart rate), and publishes FHIR Observation resources to a local buffer. When connectivity is available, the buffer pushes to the cloud platform. When connectivity fails, the buffer holds up to 72 hours of readings.

A cloud FHIR server registered as an ABDM HIP. This is the component most deployments skip. The HIP registration process takes 6 to 10 weeks with NHA and requires a security audit of data access controls. Until this is complete, no data can flow to ABHA records. The clinical system can still receive data, but the ABHA linkage and cross-institution sharing that give ABDM its value are unavailable.

A consent management service. Codelynks built a microservice that subscribes to ABDM’s consent grant and revocation webhooks, maintains per-patient consent state, and gates all FHIR data pulls at the API layer. When a consent expires, the service queues a renewal request to the patient’s ABDM consent manager and blocks new HIU pulls until renewal is confirmed.

A clinical alert layer. The FHIR Observation stream feeds a configurable rule engine. Atrial fibrillation detection triggers an alert to the treating physician’s HIMS worklist within 90 seconds of a flagged ECG reading, whether the patient is at home, at a CHC, or in a district hospital.

Best Practices for Successful ABDM IoT Integration

Every RPM vendor promises FHIR compliance. Ask them which FHIR version, which resource profiles, and which ABDM HIU onboarding documentation they have shipped. FHIR R4 and DSTU2 are not compatible. A vendor who shipped “FHIR” for a US client in 2021 and has not updated to NHA’s 2024 Implementation Guide profiles is not compliant with ABDM Phase 2.

This week: pull the AIIRS assessment template and score your current or planned RPM deployment across the five dimensions. If you score below 6, the deployment is not production-ready for ABDM Phase 2 connectivity. The most impactful fixes are HIP registration (start now, the queue is long) and consent lifecycle automation.

IoT Remote Patient Monitoring ABDM Integration India provides hospitals with a secure and scalable framework for remote patient monitoring, interoperability, and nationwide healthcare data sharing.

More Blogs: RBI, AFA Mandate UPI Performance, Engineering, Fintech