AutoSifu

01 — Under one roof

One routeto type approval.

Compliance, engineering and the certificate are usually three vendors and three vocabularies. Here they are one route, walked with the body that grants the approval.

01

Compliance

CSMS and SUMS built as management systems, not documents. Gap assessment against ISO/SAE 21434 and ISO 24089, risk assessment and TARA, process and policy an auditor can follow end to end.

  • Gap assessment
  • TARA & risk
  • Policy & process
  • Audit readiness
UN R155 · AIS-189
02

Solutioning

The engineering that makes the paperwork true. Secure OTA and update workflow, PKI and key management, RxSWIN generation, bootloader and rollback logic, diagnostics hardened across UDS, DoIP and SOVD.

  • Secure OTA
  • PKI & keys
  • RxSWIN
  • Rollback & recovery
UN R156 · AIS-190
03

CoC / VTA

The evidence pack assembled the way the approval authority reads it, and carried through submission, review and post-approval monitoring as software keeps shipping.

  • Evidence pack
  • Submission
  • Review support
  • Post-approval
Homologation dossier
Route to approvalA single line running left to right through seven stages of type approval: the CSMS and SUMS management systems, item definition, TARA, concept and requirements, verification and evidence, agency assessment, and finally vehicle type approval, which is marked as the completion point. The same seven stages are listed as text immediately below the figure.01CSMS · SUMSCertificate ofCompliance for CSMSUN R155 §7.2 ·AIS-189 §6.102ITEM DEFINITIONBoundary, interfaces,assumptionsISO/SAE 21434 §9.303TARARisk assessment forthe itemISO/SAE 21434 §1504CONCEPT &REQUIREMENTSCybersecurity goalsand requirementsISO/SAE 21434§9.4–9.505VERIFICATION &EVIDENCEResults and theassembled dossierISO/SAE 21434§10–1106AGENCY ASSESSMENTAssessment by thetest agencyAIS-189 §6.107VEHICLE TYPEAPPROVALType approval for thevehicle typeUN R155 §7.3Route to approvalA single line running left to right through seven stages of type approval: the CSMS and SUMS management systems, item definition, TARA, concept and requirements, verification and evidence, agency assessment, and finally vehicle type approval, which is marked as the completion point. The same seven stages are listed as text immediately below the figure.01CSMS · SUMSCertificate of Compliance for CSMSUN R155 §7.2 · AIS-189 §6.102ITEM DEFINITIONBoundary, interfaces, assumptionsISO/SAE 21434 §9.303TARARisk assessment for the itemISO/SAE 21434 §1504CONCEPT & REQUIREMENTSCybersecurity goals and requirementsISO/SAE 21434 §9.4–9.505VERIFICATION & EVIDENCEResults and the assembled dossierISO/SAE 21434 §10–1106AGENCY ASSESSMENTAssessment by the test agencyAIS-189 §6.107VEHICLE TYPE APPROVALType approval for the vehicle typeUN R155 §7.3
FIG. 01 — ROUTE TO APPROVAL · REF. UN R155 §7.2–7.3 · AIS-189 §6.1 · ISO/SAE 21434 §9–11

— Before this

Until now a programme had two options, and both left a gap.

Buy a product

  • Covers one segment of the route — a platform, a scanner, a tool.
  • The programme still assembles its own evidence.
  • The programme still faces the agency alone.

Hire a consultancy

  • Covers a different segment — the analysis, the concept, the gap report.
  • Hands over a document and stops before the assessment.
  • The programme carries it into the agency alone.
One route, one roof.See the route
Cybersecurity lifecycleA V-shaped diagram of the ISO/SAE 21434 cybersecurity lifecycle. The left leg descends through item definition, TARA, cybersecurity goals, cybersecurity concept and architectural design. Implementation sits at the fold. The right leg ascends through integration and verification, validation, and assessment, which is marked as the completion point. Three coverage bands above the V show that AutoSifu spans both legs, while a typical product vendor covers only part of the right leg and a typical consultancy only part of the left. A dashed enclosure around the whole lifecycle marks the CSMS and SUMS management systems. Buttons below the figure select a coverage band to highlight the stages it spans and dim the rest; a readout names the covered stages and their count.CSMS · SUMS — MANAGEMENT SYSTEMS, ASSESSED AT MANUFACTURER LEVELAUTOSIFU WITH CIRTTYPICAL PRODUCT VENDORTYPICAL CONSULTANCYITEM DEFINITION§9.3TARA§15CYBERSECURITY GOALS§9.4CYBERSECURITY CONCEPT§9.5ARCHITECTURAL DESIGN§10IMPLEMENTATION§10INTEGRATION & VERIFICATION§10VALIDATION§11ASSESSMENT§6Cybersecurity lifecycleA V-shaped diagram of the ISO/SAE 21434 cybersecurity lifecycle. The left leg descends through item definition, TARA, cybersecurity goals, cybersecurity concept and architectural design. Implementation sits at the fold. The right leg ascends through integration and verification, validation, and assessment, which is marked as the completion point. Three coverage bands above the V show that AutoSifu spans both legs, while a typical product vendor covers only part of the right leg and a typical consultancy only part of the left. A dashed enclosure around the whole lifecycle marks the CSMS and SUMS management systems. Buttons below the figure select a coverage band to highlight the stages it spans and dim the rest; a readout names the covered stages and their count.ITEM DEFINITION§9.3TARA§15CYBERSECURITY GOALS§9.4CYBERSECURITY CONCEPT§9.5ARCHITECTURAL DESIGN§10IMPLEMENTATION§10INTEGRATION & VERIFICATION§10VALIDATION§11ASSESSMENT§6
FIG. 02 — CYBERSECURITY LIFECYCLE · REF. ISO/SAE 21434 §9–11

— The assessing agency

Rule 126 names the institutions. It does not confer scope.

Rule 126 of the Central Motor Vehicles Rules, 1989 names the institutions to which a vehicle prototype may be submitted for test. The Central Institute of Road Transport, Pune was added to that list by G.S.R. 276(E), dated 10 April 2007.

That notification does not by itself confer cybersecurity scope. AIS-189 clause 5.3.1 handles competence separately: the assessing agency must hold automotive cybersecurity and risk assessment competence of its own. Which is why this work happens alongside the agency — and why the difference between being named on a list and holding the scope is worth knowing before you plan a programme around it.

03 — IT / OT

The attack does not respect your org chart.

R155 does not stop at the vehicle. A CSMS has to hold across the plant that builds the ECU, the backend that signs the update, and the car that installs it. Most programmes secure one of the three and describe all three.

OT

The plant

Production line, flashing stations, MES and the PLC/SCADA estate. IEC 62443 territory — and the place where an unsigned image or a loose key enters the fleet before a single vehicle leaves the gate.

IT

The backend

Update backend, PKI and certificate lifecycle, vehicle SOC, campaign management. Where RxSWIN is generated, and where the audit trail either exists or does not.

VEH

The vehicle

Gateways, domain controllers, telematics, charging and diagnostics. The zones, and the paths between them — which is what UN R155 Annex 5 actually enumerates.

04 — Evidence

A bench, not a slide deck.

CAN bus fuzzing and UDS attacks against representative ECU setups. No production vehicle involved. This is where a claim becomes a finding — and where a finding becomes the evidence an approval authority will accept.

A live demonstration at the Automotive Cybersecurity Penetration Testing Laboratory: a bench carrying a laptop running CAN analysis, a bench power supply, and printed CAN Bus Attack and UDS Attack procedure sheets.
Automotive Cybersecurity Penetration Testing Laboratory, CIRT Pune — live demonstration for the Transport Commissioner, Maharashtra.

The readout, under attack

Four states, in order: the cluster agreeing with the vehicle, crafted frames arriving on the bus, the readout diverging, and diagnostics still reporting nothing wrong. Scroll it, or step through it.

Instrument cluster · live◆ nominal
State of charge78 %
Speed0 km/h

Reading matches the vehicle.

Step through
CAN

Bus fuzzing

Injecting crafted and unexpected messages into the in-vehicle network until something gives.

UDS

Signal manipulation

Unauthorised message injection and manipulation of safety-critical signals over diagnostics.

→

The conclusion

Authentication, secure communication and continuous testing must be designed in, not added.

— Coverage

Where your approval is valid.

One approval, issued once, accepted across every market that recognises the UN regulations. A national approval stops at its own border — which is the whole reason an exporting programme carries two files.

Where an approval is validA world map. Markets that accept a UN type approval are filled solid; India and China, which run their own national regimes, are hatched; everywhere else is outlined only. The same information is listed as text beside the map.
Accepts a UN approvalOwn regime — approval stops at the borderNo equivalent requirement

Select a market to see how far an approval issued there travels.

— Scope

What we work to, and which edition.

The version matters. A CSMS built to one series of amendments is not automatically a CSMS under the next.

UN R155Cyber Security Management System01 series of amendments
UN R156Software Update Management System01 series of amendments
AIS-189CSMS — IndiaAs notified
AIS-190SUMS — IndiaAs notified
ISO/SAE 21434Road vehicles — cybersecurity engineering2021
ISO 24089Road vehicles — software update engineering2023
IEC 62443Industrial automation and control systemsSeries
EU CRACyber Resilience Act(EU) 2024/2847

Editions shown are those we currently deliver against. Where a series is superseded mid-programme we say so in the assessment scope, not afterwards.

09 — Start here

Bring us the file you are least sure about.

Most conversations start with a gap assessment, or a type approval submission that is closer than it feels. Either is a good place to begin.

Direct

Jaipur · registered office

Plot No. 8, ABS Plaza, Chanakya PuriJagatpura, Jaipur – 302017, RajasthanAUTOSIFU Pvt Ltd · India

Required