They should use both, but for different questions. Gateway controls limit traffic and policy scope, while attestation helps prove the client is the genuine application. For sensitive vehicle functions, attestation is what closes the trust gap that gateway rules cannot see.
Why gateway controls answer a different question than attestation
api gateway controls and application attestation solve different trust problems, so automakers should not treat them as substitutes. A gateway can limit who reaches an API, shape traffic, and enforce coarse policy. Attestation answers a harder question: whether the caller is the intended application, running in the expected state, before the vehicle function trusts the request.
That distinction matters because an API gateway mostly sees network and token presentation, while attestation is about proving the software endpoint itself. For automotive backends that broker remote commands, telemetry, diagnostics, or entitlement checks, the trust gap is not just “is this request allowed”, but “is this request coming from the genuine client we meant to trust”.
For API-centric systems, that is the same boundary problem addressed in the API Security Guide and the OWASP API Security Top 10: access control at the edge is necessary, but it does not by itself prove request provenance or stop a legitimate credential from being used by the wrong client.
Where attestation matters most in vehicle operations
Attestation becomes most valuable when an automotive service can trigger safety-relevant or sensitive actions, such as unlocking features, starting a session, modifying vehicle state, or retrieving high-value data. In those flows, a gateway can confirm the connection path and policy state, but it cannot reliably distinguish a genuine app build from a repackaged or instrumented clone using stolen credentials or copied API calls.
That is why teams should think of attestation as a client authenticity control, not a traffic-shaping control. It gives the backend a stronger signal that the caller is the approved application instance, which is especially important when the same API surface may be reachable from consumer apps, dealer tooling, partner integrations, and automated services.
This is the same design pressure described in the NHI Authentication Guide, where the core issue is proving that a non-human caller is the right caller, not merely an authenticated caller. For app-to-service trust, attestation strengthens the authentication story rather than replacing it.
How automakers should sequence the control choice
Gateway controls should come first when the immediate problem is exposure management: reducing attack surface, enforcing rate limits, filtering obvious abuse, and ensuring only intended endpoints are reachable. Attestation should move up the stack when the question becomes whether a request should be trusted enough to execute a protected vehicle action.
In practice, the right sequence is not either-or. Start with gateway policy to constrain traffic, then add attestation where the business impact of impersonation, replay, or client substitution is material. If a compromised or cloned app can still satisfy the gateway, the gateway has done its job, but the trust model is still incomplete.
The same layered approach is reflected in the SPIFFE workload identity specification, which treats identity proof and trust establishment as separate from perimeter filtering. For automakers, that separation is useful: perimeter controls reduce noise, attestation reduces impersonation risk.
Risk and Threat Considerations
Vehicle-facing APIs are attractive targets because they often sit between consumer apps and high-value actions. If teams rely on gateway policy alone, an attacker who steals a valid token, instruments the app, or replays a legitimate request path may still reach the backend with enough legitimacy to bypass coarse edge checks.
Failure mechanism: A gateway enforces source, rate, or policy constraints, but the backend lacks a strong proof that the caller is the intended application instance, so a copied or abused credential can still drive sensitive requests.
Impact: The result can be unauthorized feature use, abuse of vehicle functions, data exposure, or fraud that looks like legitimate traffic until deeper client validation is added.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | API client trust and request legitimacy are central to the question. |
| API5 — Broken Function Level Authorization | Gateway scope and backend function control both affect who can invoke vehicle operations. | |
| Recommendation — Bind sensitive vehicle actions to stronger client authentication and trust signals than gateway policy alone. Enforce function-level checks on every vehicle action, not just at the API edge. | ||
| OWASP ASVS | V6 — Authentication | Attestation strengthens the authenticity check for the calling application. |
| V8 — Authorization | The question is about how access decisions are enforced across gateway and backend layers. | |
| Recommendation — Require stronger caller authentication evidence for sensitive app-to-service interactions. Validate authorization at the business action, not only at the gateway. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Automotive app-to-backend trust is a service-to-service authentication problem. |
| AC-3 — Access Enforcement | Gateway controls enforce coarse access decisions while backend policy enforces final access. | |
| Recommendation — Authenticate services with mechanisms that prove the caller’s identity before allowing sensitive actions. Apply access enforcement at both the edge and the protected function. | ||
Practitioner Guidance
What to prioritise: Put gateway controls around exposure, then reserve attestation for flows where client impersonation changes the security outcome. If a request can trigger a vehicle state change or privileged backend action, attestation deserves higher priority than another layer of edge filtering.
What to verify: Confirm that the attestation signal is actually bound into the authorization decision, not just logged after the fact. If the backend will execute the same action whether the attestation passes or fails, the control is only ornamental.
Practitioner takeaway: Gateway controls manage access paths, but attestation manages trust in the client itself, and for sensitive vehicle functions that difference is what determines whether the request is merely allowed or genuinely trustworthy.
Related resources from NHI Mgmt Group
- How do security teams decide whether to prioritise gateway controls or edge filtering first?
- How do organisations decide whether to invest first in an AI gateway or in per-application controls?
- Should organisations prioritise API discovery or runtime controls first?
- What are the first controls to prioritise for application allowlisting?
Deepen Your Knowledge
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.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org