AIS-189: Automotive Cybersecurity Standard for India
- Home
- AIS-189: Automotive Cybersecurity Standard for India
Why AIS-189 Exists
Cars today are not just mechanical systems; they are complex computer networks on wheels.
A modern vehicle may have 100+ ECUs, each connected through CAN, LIN, or Automotive Ethernet, exchanging millions of messages per second.
With connectivity comes exposure — to hackers, spoofing, firmware tampering, and even remote control attacks.
Globally, regulations like UNECE R155 and ISO/SAE 21434 were created to ensure vehicles are designed with cybersecurity in mind.
India followed this global direction through AIS-189 a standard that mandates:
Cybersecurity-by-design in all automotive electronics.
A secure software and hardware development process.
Continuous monitoring and post-production updates.
By 2027, every new vehicle sold in India
must comply with AIS-189
This isn’t just a compliance issue
It’s about building trust between drivers, manufacturers, and the digital systems that move us.
AIS-189: Automotive Cybersecurity Services
by Gettobyte
What it is
A Cybersecurity Management System is the backbone of AIS-189.
It ensures your organization has defined roles, processes, and documentation to manage cybersecurity throughout a vehicle’s life cycle — from concept to decommissioning.
Why it’s needed
Without a CSMS, security becomes accidental.
AIS-189 requires OEMs to demonstrate policy-driven governance, not just technical patches.
Auditors ask for traceable workflows, version-controlled evidence, and defined responsibilities.
How Gettobyte helps
- Gap assessment of your current processes.
- Creation of policies for cryptography, vulnerability, and incident handling.
- Definition of roles (CSM, project engineers, suppliers) with RACI mapping.
- Integration into tools like Jira / Polarion / Confluence for full traceability.
- Training for internal teams on audit readiness.
Deliverable: CSMS Policy Pack + ALM Traceability Dashboard + Training Deck.
2. Threat Analysis and Risk Assessment (TARA) |
Do you know your attack surfaces and how to protect them?
What it is
TARA (Threat Analysis and Risk Assessment) identifies assets, potential attacks, their impacts, and mitigation controls.
It transforms abstract threats into actionable security goals.
Why it’s needed
AIS-189 requires proof that every security measure (e.g., SecOC, TLS, Secure Boot) originates from a risk-based justification.
Without TARA, controls appear arbitrary and fail audits.
How Gettobyte helps
- Identify ECU assets and communication channels.
- Model threats using STRIDE + attack trees.
- Score risks (impact × feasibility).
- Define security goals and technical requirements.
- Map to relevant AUTOSAR modules or crypto primitives.
Deliverable: Risk Register + Security Goals Matrix + Verification Mapping.
3. Secure ECU Design & Implementation
How are ECUs technically protected against cyber attacks?
What it is:
This chapter is the heart of embedded cybersecurity — building ECUs that can authenticate, encrypt, and verify themselves.
It covers the principles behind secure hardware, trusted execution, cryptographic enforcement, and how an ECU maintains its integrity throughout the entire automotive lifecycle — from design, production, and service to long-term updates.
In short, this section defines what makes an ECU “trustworthy” in the first place.
Why it’s needed
Even the best process fails if the firmware and hardware can be tampered with.
AIS-189 requires secure ECU development, covering Secure Boot, communication authentication, diagnostics, and encryption.
The purpose is to ensure that safety-critical systems remain uncompromised throughout the vehicle’s entire operational life.
How Gettobyte helps
- Secure Boot with signature verification via HSE or TrustZone.
- SecOC for CAN/Ethernet message authentication and freshness.
- UDS hardening: seed-key via hardware crypto, rate limits, lockouts.
- DoIP / TLS for authenticated diagnostics over IP.
- AUTOSAR Crypto stack (Csm, CryIf, SecOC) integration.
- Implementation on NXP S32K344 / S32G / STM32H7 platforms.
Deliverable: Secure ECU firmware + Configuration Guide + Demo Logs.
4. Verification and Pen-Testing
Can you prove your ECUs resist attacks?
What it is
Verification validates that implemented controls actually work — under fuzzing, tampering, and real attacker behavior.
The goal is to confirm that security measures hold up consistently, detect anomalies early, and prevent silent failures that might otherwise go unnoticed during normal operation.
Why it’s needed
AIS-189 demands measurable evidence, not promises.
Testing must show how the ECU reacts to malformed packets, replay attacks, or intrusion attempts
OEMs and suppliers must prove that attacks cannot bypass protections and that systems maintain safe, predictable behavior even under stress or adversarial conditions.
How Gettobyte helps
- Fuzz testing of UDS, DoIP, and SOME/IP using CANoe + boofuzz.
- Pen-tests for replay, DoS, tampering, and key extraction attempts.
- Automation pipelines to rerun tests with every firmware iteration.
- Documentation aligned with ISO 21434 verification work products
Deliverable: Fuzz Reports + PCAP Evidence + Pen-Test Summary + Regression Scripts.
5. PKI and Key Management
Who holds the keys to your vehicle’s trust?
What it is
Public Key Infrastructure (PKI) manages digital identities — certificates, signing keys, and access control for every ECU and backend system.
PKI ensures that each component can prove its identity, authenticate securely, and participate in trusted communication without the risk of impersonation or unauthorized access.
Why it’s needed
Without proper key lifecycle management, even secure boot or TLS becomes meaningless.
AIS-189 mandates secure key generation, storage, provisioning, and revocation.
Strong PKI is essential to ensure that ECUs, vehicles, and cloud platforms continuously operate within a validated trust framework throughout manufacturing, service, and long-term field operation.
How Gettobyte helps
- Root / Intermediate CA setup for OEM and suppliers.
- Certificate Policy & CPS documentation.
- On-device key generation through HSM/HSE.
- Provisioning scripts for ECU manufacturing.
- Mutual TLS configuration between ECUs and servers.
- Revocation & renewal workflow for long-term operation.
Deliverable: PKI Architecture + Certificates + Key Provisioning Toolchain.
6. Implementation of Hardware Security: HSM, SHE, and TrustZone
What anchors your security — hardware or hope?
What it is
Hardware Security Modules (HSM / HSE / SHE) and ARM TrustZone form the silicon-level root of trust, isolating cryptographic secrets from the main CPU.
They enable secure execution environments where authentication, encryption, and firmware validation happen under strict, tamper-resistant hardware control.
Why it’s needed
Software alone can be bypassed.
AIS-189 expects cryptographic keys to be non-exportable, debug interfaces locked, and firmware verified by immutable hardware logic.
By enforcing security at the hardware level, ECUs gain resilience against cloning, unauthorized reprogramming, firmware tampering, and sophisticated attacker techniques used in real-world exploitation scenarios
How Gettobyte helps
- Configure HSE firmware on NXP S32K3/S32G for key catalogs, counters, and secure boot.
- Implement SHE-based symmetric security on S32K1 family for cost-effective ECUs.
- Partition TrustZone-M environments (Secure vs Non-Secure).
- Demonstrate anti-rollback, secure debug unlock, and performance benchmarking.
Deliverable: Hardware-secured firmware demo + Lifecycle Control Guide + Benchmarks
7. Development of Security Software Update & Post-Production Cybersecurity
Can your vehicles stay secure after they leave the factory?
What it is
Post-production cybersecurity ensures vulnerabilities can be patched safely — via secure software updates, monitoring, and incident response.
This phase ensures that ECUs remain protected against newly discovered weaknesses, emerging attack techniques, and evolving threat patterns encountered during real-world usage.
Why it’s needed
Threats evolve after deployment. AIS-189, aligned with UNECE R156, requires OEMs to manage vulnerabilities and deliver authenticated, traceable, anti-rollback software updates.
Without a strong post-production cybersecurity process, vehicles remain exposed to unpatched vulnerabilities, outdated firmware, and undetected attacks that can compromise safety and reliability over time.
How Gettobyte helps
- HSE-verified bootloader for signature and anti-rollback.
- TLS-protected OTA pipelines (backend → T-Box → ECU).
- Firmware signing toolchain with OEM private keys.
- SBOM + CVE tracking system for vulnerability management.
- Incident Response workflows for detection and containment.
- Integration with in-vehicle IDS agents for anomaly detection.
Deliverable: Secure Bootloader + OTA Demo + Vulnerability Dashboard + IR Playbook.