Published on May 1, 2026

How Runtime Monitoring Secures Automotive APIs

Maxwell

@carsxe_api

automotive API securityruntime monitoringmTLStelemetry signinganomaly detectionrate limitingUNECE R155ISO 21434

How Runtime Monitoring Secures Automotive APIs

Modern vehicles rely heavily on APIs to connect Electronic Control Units (ECUs), mobile apps, and cloud services. This connectivity brings convenience but also exposes vehicles to cyber threats, such as unauthorized access, credential stuffing, and data tampering. Runtime monitoring addresses these risks by continuously analyzing API traffic to detect anomalies and block threats in real time.

Key Takeaways:

API Vulnerabilities: Common issues include Broken Object Level Authorization (BOLA), credential stuffing, and replay attacks.
Runtime Monitoring Benefits: Tracks API traffic, enforces security measures like mTLS (mutual TLS), and identifies unusual activity.
Regulatory Compliance: Standards like UNECE R155 and ISO 21434 require automakers to maintain active cybersecurity measures throughout a vehicle's lifecycle.
Core Security Tools: API gateways, telemetry signing, anomaly detection, and rate limiting protect against attacks.

Security Threats Targeting Automotive APIs

Common API Security Risks in Automotive Systems

Automotive APIs are exposed to a variety of threats that go beyond standard data breaches. One of the most exploited vulnerabilities is Broken Object Level Authorization (BOLA). Attackers can manipulate identifiers like Vehicle Identification Numbers (VINs) or user IDs to bypass security measures, gaining unauthorized access to vehicle data or even issuing commands. For instance, in 2024, a vulnerability allowed attackers to export 17,000 customer records from a single automaker.

Another major risk is credential stuffing, where stolen login credentials are used to access vehicle owner accounts. This can result in unauthorized commands being executed or sensitive data being leaked. A notable example occurred in March 2026, when a cyberattack on an ignition interlock device provider disabled approximately 150,000 devices across 46 states in the U.S..

Enumeration attacks are also a concern. By exploiting sequential VINs, attackers can uncover valid user accounts or vehicle records. Furthermore, unauthenticated API endpoints, often stemming from internal or development APIs that are unintentionally exposed, can provide access to sensitive telemetry data or personally identifiable information (PII).

Advanced threats like telemetry tampering allow attackers to alter data transmitted from vehicles to cloud systems. This can lead to issues such as insurance fraud or disruptions in fleet management. Similarly, replay attacks, where previously captured command messages (like "unlock door") are resent, can trigger unauthorized actions.

The risks extend even further. Each Electronic Control Unit (ECU) within a vehicle represents a potential attack surface. As Darren Shelcusky from Ford Motor Company aptly puts it:

"Playing cybersecurity 'whack-a-mole,' where individual security threats are addressed as they pop up, is far from optimal".

These vulnerabilities can have severe consequences, including remote vehicle control, disabling of critical safety systems, real-time location tracking, and theft of customer data. The increasing complexity of these threats underscores the importance of regulatory measures aimed at ensuring continuous threat detection and mitigation.

Meeting Regulatory Compliance Requirements

To tackle these evolving risks, regulators are enforcing stricter security requirements. Runtime monitoring, once considered a best practice, is now becoming a legal necessity. For example, UNECE R155 mandates that automakers implement active cybersecurity measures throughout a vehicle's lifecycle. This includes responding to detected cyberattacks within a "reasonable time frame". This regulation has shifted the focus of automotive cybersecurity from being a development-stage concern to a full-lifecycle responsibility, making ongoing monitoring of vehicles in the field indispensable.

As the Uraeus Engineering Team notes:

"R155 does not prescribe specific monitoring technologies or architectures. It requires outcomes: that threats are detected, that vulnerabilities are identified, and that responses occur within reasonable timeframes".

Compliance with these regulations demands that manufacturers maintain detailed evidence, such as VSOC (Vehicle Security Operations Center) dashboard exports, alert logs, SBOM (Software Bill of Materials) scan reports, and incident response records. Additional standards, such as UNECE R156 and ISO/SAE 21434, further emphasize the need for robust, continuous monitoring capabilities.

sbb-itb-9525efd

How Runtime Monitoring Protects Automotive APIs

Core Runtime Monitoring Mechanisms

Runtime monitoring creates multiple layers of defense to detect and stop threats before they can affect vehicle systems. At the heart of this setup are API gateways. These act as a centralized checkpoint where key security measures like authentication, rate limiting, and Web Application Firewall (WAF) protections are applied before requests reach backend automotive services. By funneling all traffic through a single point, it becomes easier to manage security and ensure consistent protection across all endpoints.

To enhance security further, mTLS (mutual TLS) is used to verify the identities of both the server and the vehicle. Unlike standard TLS, which only authenticates the server, mTLS requires both parties to present certificates. These certificates are securely stored in hardware, such as Trusted Platform Modules (TPM) or Secure Elements, ensuring that private keys never leave the vehicle. This safeguard prevents attackers from impersonating vehicles, even if credentials are compromised.

Sliding window algorithms are another critical tool. They enforce tiered rate limits at multiple levels - per user, per endpoint, and globally. This ensures that legitimate users can continue using the system without disruption, while large-scale abuse is curtailed.

For data integrity, telemetry signing plays a key role. Vehicles use algorithms like ECDSA (P-256) or Ed25519 to sign telemetry data, and the backend verifies these signatures to ensure the data hasn’t been tampered with. This not only guarantees authenticity but also creates an immutable audit trail, which is crucial for meeting compliance standards like UNECE R155 and ISO 21434. Additionally, replay protection mechanisms, such as monotonic sequence numbers, timestamps, and one-time nonces, prevent attackers from reusing captured commands.

Finally, anomaly detection systems work in the background to identify unusual patterns that might signal an attack. These systems flag issues like geographic anomalies (e.g., a vehicle suddenly accessing APIs from an unexpected location), spikes in failed mTLS handshakes, or sequence number irregularities that could indicate replay attempts. As Veld Systems aptly states:

"If your API security strategy stops at authentication, you are leaving the front door locked while the windows are wide open." - Veld Systems

These mechanisms are not just theoretical - they’re actively deployed in real-world scenarios.

Runtime Monitoring in Action: Automotive API Examples

Runtime monitoring’s layered approach is essential for protecting a variety of automotive APIs. Take, for instance, a VIN decoding API that provides vehicle specifications and history. When a request is made, the API gateway first checks the client’s mTLS certificate against a fast-path revocation cache - an in-memory denylist that can block compromised devices almost instantly. Next, the system ensures the request rate stays within acceptable limits. If all checks are passed, a WAF inspects the payload for issues like SQL injection attempts or malformed VINs.

For vehicle history APIs that handle sensitive information like ownership and accident data, runtime monitoring goes a step further. It ensures that the user is authorized to access the specific VIN being queried, reducing the risk of Broken Object Level Authorization (BOLA) attacks. To protect tokens, the system uses short-lived telemetry tokens (30–300 seconds) and critical control tokens (10–60 seconds), making intercepted tokens useless within a short time frame.

Market value APIs, which deliver real-time pricing data, benefit from anomaly detection to guard against scraping attempts. The system monitors for suspicious patterns, such as sequential VIN queries, traffic from data center IPs, or sudden activity spikes from new accounts. When such behavior is detected, the system can automatically throttle the client, demand additional authentication, or block the connection entirely - no manual intervention needed.

These examples illustrate how runtime monitoring provides dynamic and adaptable defenses for a wide range of automotive API use cases.

APISEC|CON Automotive: Automotive API Security Risks: Frontline Insights from the Vehicle SOC

Setting Up Runtime Monitoring for Automotive APIs

Automotive API Security Monitoring Metrics and Alert Thresholds

Deploying Runtime Monitoring Through API Gateways

To effectively monitor your automotive APIs, start by deploying monitoring plugins at the API gateway level. If you're using Kong, the Prometheus plugin is a great choice. It captures essential metrics like request rates, latency, and error rates, giving you a clear view of how clients interact with your APIs before their requests even hit the backend services.

Structured logging is another critical step. Configure logs in JSON format and include key details such as timestamps, correlation IDs (also known as Request IDs), client IPs, HTTP status codes, and latency. These elements help you trace individual requests throughout your system, from the gateway to internal microservices. As API7.ai points out:

"In a cloud-native environment, observability is not an add-on; it is a first-class concern".

To gain a complete picture of your system's performance, configure Prometheus to scrape metrics from both your API gateway and internal sidecars like Dapr. This setup allows you to track metrics specific to automotive APIs, such as signature verification failures, vehicle error rates, and the performance of diagnostic sequences.

It's also essential to protect sensitive information. Use data redaction techniques to mask or exclude personally identifiable information (PII), vehicle identification numbers (VINs), and tokens to comply with regulations like GDPR. For alerting, establish a multi-tiered system with severity levels - Critical, High, and Low - based on Service Level Objective (SLO) violations. For instance, trigger critical alerts when error rates exceed 5% or latency surpasses SLA limits.

Once the gateway deployment is set up, the next step is to configure anomaly detection rules to catch threats early.

Setting Up Anomaly Detection Rules

Anomaly detection rules are your early warning system for potential issues. Focus on key performance indicators, often referred to as the "Golden Signals": request rate (RPS), latency percentiles (P50, P90, P99), and error rates (4xx and 5xx responses). For automotive APIs, also monitor metrics like signature verification failures and vehicle error rates.

Using Prometheus queries (PromQL), you can calculate real-time error rates. Here's an example query to calculate the percentage of 5xx errors over a 5-minute window:

sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100

Set alert thresholds based on your industry's standards and SLAs. For instance, warnings might trigger at an error rate of 1%, with critical alerts at 5%. Below is a table of recommended thresholds for monitoring automotive APIs:

Metric Security/Operational Threat Recommended Alert Threshold Signature Verification Failures Spoofing, Unauthorized Access > 5 in 5 minutes Processing Error Rate System Instability, Exploits > 5% of events P99 Latency Resource Exhaustion, DoS > 1,000ms VEHICLE_ERROR Rate Hardware/Signal Failure > 10% of vehicles Queue Depth System Overload > 1,000 messages

Monitoring P99 latency is crucial for catching delays that could disrupt the user experience. A common warning threshold is 1,000ms. For asynchronous tasks, such as vehicle state updates, set alerts to trigger if the queue depth exceeds 1,000 messages to avoid data becoming outdated. As Yilia Lin from API7.ai notes:

"Real-time alerts are not just a luxury - they're a necessity for maintaining uptime, ensuring compliance, and delivering seamless user experiences".

Testing and Going Live

Before going live, test your monitoring setup in a staging environment. Ensure that invalid or spoofed requests are being logged correctly through signature verification. Check that correlation IDs are propagating across all downstream services for complete traceability. Also, confirm that sensitive data like VINs and tokens are properly masked in your logs.

Another critical step is verifying idempotency to prevent duplicate processing of webhook or API events. Use real staging traffic to fine-tune alert thresholds. For example, set "Warning" alerts when consumers hit 80% of their quota and "Critical" alerts when legitimate internal traffic is throttled. Nawaz Dhandala from OneUptime puts it well:

"Rate limiting without monitoring is like having a fire alarm with no sound".

To further test your system's resilience, use chaos engineering tools like Chaos Monkey to simulate failures and ensure your alerts are firing correctly. Test endpoint performance against specific timeout limits - automotive webhooks should respond within 10–15 seconds. Finally, create runbooks with step-by-step instructions for handling common failures, such as SSL certificate expiration, to minimize recovery time. Implement log rotation and retention policies (typically 30–90 days) to manage storage costs in high-traffic environments.

Once all tests are successful and alerts are calibrated, deploy your setup to production. Keep a close eye on the system during the first 48 hours and adjust thresholds as needed based on actual traffic patterns. This ensures your monitoring system is ready to handle the demands of real-world operations.

Best Practices for Automotive API Security

Pairing Runtime Monitoring with Continuous Validation

To make runtime monitoring more effective, pair it with strong authentication measures. One key step is enforcing mTLS (mutual TLS), which binds server and device identities using hardware-based roots-of-trust, like TPMs (Trusted Platform Modules) or Secure Elements. This creates a hardware-backed identity that is far more difficult for attackers to spoof or steal.

For APIs handling high traffic, use PoP (Proof of Possession) tokens with short lifetimes. For telemetry data, set token lifetimes between 30–300 seconds, while critical commands should use even shorter lifetimes of 10–60 seconds. These short-lived tokens minimize the risk of exploitation if credentials are leaked.

To ensure telemetry data remains intact, sign it at the edge using device private keys (e.g., ECDSA or Ed25519) and standardized serialization formats like CBOR/COSE. Add replay protection by including monotonic sequence numbers and timestamp skew windows (±60 seconds) to block command injection attempts.

An API gateway is another must-have. It handles tasks like coarse-grained authorization, mTLS handshakes, and initial token validation. This setup prevents your core API from being bogged down by frequent introspection calls. As noted by Curity:

"The use of API gateways reduces unauthorized calls to APIs... APIs are not running the initial token validation and frequent introspection calls".

Using Tamper-Proof Logs for Compliance

After establishing real-time validation, tamper-proof logging is the next line of defense. This is especially important for meeting compliance standards like UNECE R155 and ISO 21434, which require auditable controls for vehicle-to-platform integrations by 2026. Use storage solutions like WORM (Write-Once-Read-Many) or blockchain-backed systems to store raw signed messages in an immutable format for forensic evidence.

Your logs should capture every processing stage in detail. This includes tracking webhook receipts, signature verification results, and any errors (complete with stack traces). Use structured JSON logging to include key details like request IDs, client IPs, HTTP status codes, and latency metrics. This format makes troubleshooting faster and more efficient.

Automate incident response for scenarios like credential leaks. For example, deploy playbooks that update revocation caches and use Over-the-Air (OTA) recovery agents to re-provision compromised devices. Keep an in-memory revocation cache in front of APIs to block compromised device thumbprints almost instantly, avoiding slow database lookups.

For APIs that serve data globally, ensure sensitive information like VINs, tokens, and personal data is masked to comply with regulations like GDPR. Set log retention policies between 30 and 90 days to balance forensic readiness with storage costs.

Maintaining Developer Productivity During Implementation

Security measures shouldn't slow developers down. Provide developer portals and DevOps dashboards that let developers monitor API security warnings and respond to alerts without needing full access to identity servers. These portals can also automate integration tracking by mapping client IDs to individual developers.

To avoid bottlenecks, use asynchronous processing for high-traffic webhook events. Log the request receipt, queue the payload, and send back an immediate success response. This prevents endpoint timeouts caused by monitoring or processing delays. Include idempotency keys to ensure duplicate requests aren't processed.

Automate credential management to keep things running smoothly. Set up rotation pipelines for cryptographic credentials, like short-lived leaf certificates, to maintain high security without manual effort. As Florence.cloud explains:

"Security for vehicle-to-platform integrations is not a one-off project. It's an operational discipline that needs automation, instrumentation, and a plan for when things go wrong".

Modern API security tools can provide full visibility across multi-cloud environments and enable quick onboarding - sometimes in as little as 15 minutes. This ensures comprehensive monitoring while keeping developer workflows intact.

Conclusion

Keeping automotive APIs secure requires constant runtime monitoring. With modern vehicles housing over 100 Electronic Control Units (ECUs), it's no surprise that API-related incidents made up 12% of automotive cyberattacks in the first half of 2023. Relying solely on static security measures simply isn't enough.

The advantages of runtime API protection are hard to ignore. It provides quick visibility across multi-cloud environments - sometimes in as little as 15 minutes - and can lead to cost savings of up to $500,000 annually for large-scale infrastructures. Beyond cost and speed, runtime monitoring ensures compliance with ISO 21434 and UNECE R155/R156 standards, offering the necessary controls and forensic evidence that today’s automotive OEMs demand. This approach strengthens the operational discipline needed to keep automotive APIs secure.

Security isn't a one-and-done task; it’s an ongoing process. Automating tasks like credential rotation, adopting mTLS with hardware-backed identity, and using short-lived tokens (30–300 seconds for telemetry) can significantly limit vulnerabilities. Setting precise alert thresholds - such as flagging more than five signature verification failures within five minutes - can help identify potential threats early. When combined with a continuous validation strategy, these steps create a strong, lasting foundation for API security.

FAQs

What’s the fastest way to add runtime monitoring to an existing automotive API?

The fastest way to introduce runtime monitoring is by setting up logging and monitoring systems that focus on critical metrics such as error rates, response times, and queue depths. Use structured logging formats like JSON for better organization and analysis. Keep an eye on webhook events and configure alerts to notify you when critical thresholds are reached. This real-time tracking and alert system helps you quickly identify issues, maintain API reliability, and gain instant insights into performance.

How do you prove UNECE R155 and ISO 21434 compliance with monitoring logs?

To meet the requirements of UNECE R155 and ISO 21434, monitoring logs need to clearly showcase robust cybersecurity measures. These logs should provide proof of continuous monitoring, the ability to detect vulnerabilities, and the execution of incident response actions. They must demonstrate that threats are being identified and mitigated in real-time, ensuring systems remain safeguarded while in operation.

What should you alert on first to detect BOLA, replay, and credential-stuffing attacks?

When securing automotive APIs, it's crucial to focus on detecting broken object level authorization (BOLA), replay attacks, and credential-stuffing attacks as top priorities. These vulnerabilities pose significant risks, such as exposing sensitive data or jeopardizing system security. Implementing early detection mechanisms for these threats can minimize potential damage and help maintain a safer API environment.