Join our Newsletter — 33% off our NHI Course
Home› Glossary› Architecture & Implementation› Automated Driving System (ADS)
Architecture & Implementation

Automated Driving System (ADS)

← Back to Glossary
By NHI Mgmt Group Updated November 3, 2026 Domain: Architecture & Implementation

An Automated Driving System is the hardware and software that can perform the driving task for a vehicle in a defined operational scope. It combines sensors, perception, planning and control, and may hand back to a human driver or operate without one depending on the design and driving conditions.

Automated Driving System architecture and scope

An Automated Driving System is not just a vehicle feature, it is the end-to-end stack that senses the environment, interprets conditions, plans actions, and executes control within a defined operational domain. That scope matters because the system’s behaviour is bounded by where, when, and under what conditions it is designed to drive.

The operational scope is what separates a capable system from a universally capable one. An ADS may perform the full driving task only in limited lanes, speeds, weather, road classes, or traffic patterns, and its design assumptions must be explicit because safety and reliability depend on those boundaries being respected.

Sensing, perception, planning, and control

The core of an ADS is a chain of functions, starting with sensors and ending with actuation. Sensors collect data, perception turns that data into a model of the road scene, planning selects the intended manoeuvre, and control converts that plan into steering, braking, and acceleration actions.

Each stage depends on the one before it, so a weakness in one part can propagate quickly through the driving stack. Misread lane markings, poor object classification, delayed planning, or unstable control logic can all produce incorrect vehicle behaviour even when the rest of the platform appears healthy.

Operational design domain and human handback

The operational design domain defines the conditions in which the ADS is intended to function. That domain is central to understanding the term because an ADS is only reliable when it remains inside its allowed environment and degrades safely when conditions move outside it.

Some designs require a human driver to take over when the system reaches its limits, while others are intended to operate without human intervention. The handback problem is therefore a key part of ADS design: if a transition is required, it must be timely, understandable, and realistic for the human to complete.

Safety, resilience, and trust in automated driving

ADS behaviour must be predictable enough for road safety, but resilient enough to handle uncertainty, degraded sensors, and changing traffic conditions. The trust challenge is that the system has to be good enough to act autonomously, yet transparent enough that operators, passengers, and regulators can understand where its limits lie.

Because the ADS continuously influences real-world motion, failures can have immediate physical consequences. Reliability, fallback behaviour, and safe-state design are therefore part of the concept itself, not separate concerns added later.

Risk and Threat Considerations

Automated Driving Systems concentrate safety-critical logic, sensors, and actuation into one trusted stack, which makes failures or manipulation high impact. The main security concern is not only whether the vehicle can drive, but whether an attacker or fault can corrupt perception, planning, or control at the point where the system makes driving decisions.

Failure mechanism: Sensor spoofing, false environment interpretation, software defects, or compromised update paths can cause the ADS to plan or execute unsafe manoeuvres, especially when the system assumes its operating conditions are still valid.

Impact: The result can be loss of vehicle control, unsafe handback, collision risk, service disruption, or broader fleet exposure if the same flaw affects many vehicles or deployments.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV.RM-01 — Risk Management StrategyADS depends on managing safety-critical operational risk across its driving scope.
PR.IR-01 — Resilience and RecoveryADS must degrade safely and recover when sensors or control functions fail.
DE.CM-01 — Networks and Systems MonitoredADS requires continuous monitoring of system behaviour and operational limits.
Recommendation — Define ADS risk tolerance and govern fallback behaviour for out-of-domain conditions. Design safe-state and recovery behaviour for ADS failures and handback events. Monitor ADS telemetry for unsafe behaviour, degraded sensing, and boundary violations.
NIST SP 800-53 Rev 5SI-4 — System MonitoringADS safety depends on monitoring control health and anomalous vehicle behaviour.
SA-11 — Developer Testing and EvaluationADS requires validation of behaviour across defined driving conditions and edge cases.
Recommendation — Implement monitoring to detect ADS anomalies in perception, planning, and control. Test ADS functions against the operational design domain and unsafe boundary cases.
ISO/IEC 27001:2022A.8.8 — Management of technical vulnerabilitiesADS software and embedded components need disciplined vulnerability handling.
Recommendation — Track and remediate ADS software vulnerabilities before they affect vehicle control.

Practitioner Guidance

What to watch for: Treat the operational design domain as a control boundary, not a marketing label. The practical question is whether the system can detect when it is outside its limits and transition to a safe fallback without relying on optimistic assumptions about the road, the weather, or the driver.

Governance implication: Ownership should cover the full ADS lifecycle, including the sensors, software stack, update process, and fallback logic. For safety-critical automation, the important judgement is not just whether the vehicle can drive, but whether the organisation can prove the system is constrained, monitored, and recoverable in the scenarios that matter.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org