Interface and behaviour rules imposed by vehicle manufacturers for projected in-car experiences. These requirements can affect notification handling, input mapping, performance, and recovery behaviour, and they often create validation gaps that do not appear in ordinary mobile testing.
Expanded Definition
OEM-specific HMI requirements are the manufacturer-defined rules that shape how an in-car experience looks, feels, and behaves on a particular vehicle platform. They sit above the app’s own logic and can govern notification timing, visual treatment, input pathways, focus handling, audio behaviour, and what happens when the projection session is interrupted or recovered.
The important boundary is that these requirements are not the same as general mobile app design guidance. They are platform-specific operational constraints that can vary by OEM, region, vehicle model, and software version. A projection experience that works correctly on one head unit can still be rejected, degraded, or made unsafe on another because the manufacturer’s HMI rules interpret the same interaction differently.
For practitioners, the common misunderstanding is assuming mobile UI validation is sufficient. It is not. The OEM layer can change state transitions, suppress content, or force fallback behaviour in ways that only appear when the app is exercised against the target vehicle environment.
Where the term overlaps with standards, the closest public reference point is the ISO 15005 road vehicles human-machine interaction guidance, which helps frame in-vehicle interaction safety, but it does not replace OEM-specific implementation rules.
Examples and Use Cases
OEM-specific HMI requirements usually become visible during integration, certification, or regression testing rather than at the feature-design stage. They affect how the same application is interpreted inside different vehicle ecosystems.
- An OEM may require navigation alerts to be reduced, delayed, or reformatted so that they do not compete with driver-critical information.
- Input mapping can differ, with one head unit accepting rotary controller events while another blocks certain gesture paths or touch interactions.
- Recovery behaviour after a phone disconnect may be constrained, for example by forcing a blank state, a safe default screen, or a manual relaunch.
- Visual refresh rates, animation timing, or content density may be limited to preserve readability and reduce distraction.
- A projection app that passes general mobile QA may still fail OEM review because a specific screen violates brand, safety, or lifecycle rules for that vehicle line.
The tradeoff is flexibility versus predictability. OEM-specific constraints reduce ambiguity in the vehicle environment, but they also make platform coverage harder because each manufacturer can enforce different interaction expectations.
Security Implications
When OEM-specific HMI requirements are misunderstood, the failure is often not a classic code defect but a control mismatch between the app and the vehicle environment. That mismatch can create unsafe interaction states, missed notifications, broken recovery flows, or rejected sessions that only surface under driving conditions or in branded head units.
Security and safety concerns overlap here because the HMI layer can suppress, defer, or reshape information at the moment it matters. If a projected interface fails to handle focus loss, reconnection, or input restrictions correctly, the result can be confusing state changes, driver distraction, or an inability to restore a trusted session cleanly.
Another practical consequence is validation blind spots. Teams may rely on ordinary mobile test cycles and miss OEM-specific constraints that alter how permissions, notification channels, or foreground behaviour are experienced in the car. That leaves a gap between nominal application behaviour and what the driver actually sees.
The practitioner observation is simple: if the vehicle platform can rewrite the interaction model, then the assurance boundary is no longer just the handset.
Domain and Governance Relevance
In connected mobility, OEM-specific HMI requirements are part of the governance boundary for in-vehicle applications. They define what the manufacturer will allow, how the experience must degrade, and which behaviours are acceptable in a safety-sensitive environment. That means product, QA, and compliance teams need to treat them as platform controls, not optional style guidance.
For identity and access-adjacent workflows, these requirements can also shape whether a session can be trusted after interruption, how re-authentication is presented, and how much action authority is exposed through the projected interface. The control question is not only whether the app is functional, but whether the vehicle can preserve a safe, bounded interaction model when conditions change.
NHI relevance is indirect rather than intrinsic. The concept is not about machine identity governance itself, but it can affect how app sessions, device connections, and trusted execution paths behave in a constrained environment. That is why OEM HMI rules matter to assurance teams even when the feature under test is not obviously security-related.
For NHIMG, the key governance point is that implementation approval should reflect the specific OEM environment, not a generic app checklist.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and EU Cyber Resilience Act and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 14 | OEM HMI validation failures often stem from missed platform-specific constraints. |
| Recommendation: Reinforces that teams must understand environment-specific behavior before release. | ||
| NIST CSF 2.0 | GV | OEM-specific HMI requirements are governance constraints on safe in-vehicle behavior. |
| Recommendation: Frames these manufacturer rules as part of organizational risk and accountability. | ||
| EU Cyber Resilience Act | Article 14 | Projected in-car software must account for lifecycle changes that can affect approved HMI behavior. |
| Recommendation: Highlights that post-release changes can alter conformance and assurance expectations. | ||
| NIS2 | Article 21 | Vehicle-facing HMI constraints create operational risk if testing omits OEM-specific behavior. |
| Recommendation: Supports managing platform-specific assurance gaps as part of risk controls. | ||
| MITRE ATT&CK | T1204 | Misleading or unsafe in-car interface behavior can influence user actions in a constrained context. |
| Recommendation: Shows how interface handling can affect human action paths during interaction. | ||
Related resources from NHI Mgmt Group
- What breaks when due diligence controls are not adapted to jurisdiction-specific AML requirements?
- What do compliance teams get wrong about jurisdiction-specific onboarding requirements?
- What do compliance teams get wrong about jurisdiction-specific KYC and due diligence requirements?
- Should organisations use new AI-specific identity standards or existing ones?
