Formula 1 identity security shows why context beats static trust

At a glance

What this is: A Formula 1 operations case study shows how context-aware access, layered defenses, and rapid control testing support secure, fast-moving digital workflows.

Why it matters: It matters because IAM teams can’t rely on one-time sign-in decisions when users, devices, and third-party systems move across environments at operational speed.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read 1Password's case study on Oracle Red Bull Racing's secure access model

Context

Formula 1 operations depend on identity decisions that move at the same pace as the business. In this case study, the control problem is not authentication alone, but whether access can stay context-aware when people sign in from different places, devices, and workflows without slowing execution.

The identity governance lesson is broader than one racing team. Enterprises increasingly need controls that adapt to context, protect specialised systems, and keep legacy or third-party platforms from becoming blind spots in otherwise well-managed IAM programmes.

Key questions

Q: How should security teams use context-aware access in fast-moving environments?

A: They should base access decisions on device posture, location, network conditions, and session risk, then tighten or expand access as those signals change. The goal is to reduce implicit trust after sign-in, especially where people move across sites, devices, and workflows that carry different risk profiles.

Q: Why do specialised or third-party systems create identity governance gaps?

A: Because many of them sit outside the core SSO and policy stack, so central controls do not fully reach them. Teams then rely on compensating controls, manual oversight, or exception handling, which is where governance usually becomes inconsistent and access risk starts to accumulate.

Q: How do you know if access controls are too friction-heavy to work in practice?

A: If users bypass controls, create support churn, or delay work to avoid the policy, the design is too heavy. The test is whether the control improves security without disrupting the actual operating rhythm of the business. Measured friction is part of governance, not a side effect.

Q: Who is accountable when identity controls fail at the edge?

A: Accountability should sit with the team that owns the exception path, not only the central IAM function. If a specialised system or vendor platform is outside the standard stack, its compensating controls, monitoring, and review cadence need a named owner and a clear escalation path.

Technical breakdown

Context-aware access in fast-moving environments

Context-aware access uses signals such as device state, location, network, and software posture to decide how much trust to grant at sign-in and during a session. That matters in high-speed operations because a single login event rarely tells the whole story. If the request comes from an unmanaged endpoint or an unexpected geography, the system can require additional verification or restrict access. The security value is not just stronger authentication, but better control over what happens after authentication.

Practical implication: align access policy with device posture and session context, not just user identity.

Layered defense for edge systems and third-party tools

Layered defense means no single control is expected to carry the full burden of protection. In distributed operations, that matters because SSO rarely covers every specialised system, vendor platform, or edge workflow. Segmentation, encryption, monitoring, and incident response each cover a different failure mode, so the loss of one layer does not expose the whole environment. The architecture is only as strong as the seams between layers, especially where third-party systems sit outside the central identity stack.

Practical implication: map every edge system to a compensating control, then test the failure path where SSO does not apply.

Why friction testing is an identity control issue

Security controls fail when they are unusable in the real workflow. Testing a new policy against live operations, measuring timing impact, and refining controls before rollout turns security from a static rule into a performance constraint that can be engineered. That is an identity problem because access controls, endpoint checks, and workflow approvals all shape whether users can work securely at speed. Controls that create delays without reducing risk are usually the first to be bypassed.

Practical implication: measure control friction before deployment and remove steps that slow work without improving risk reduction.

NHI Mgmt Group analysis

Static trust is the wrong model for fast-moving operations. This case study shows that security decisions must follow the request context, not just the user account. When access is granted once and treated as stable, teams miss the operational reality that devices, locations, and work patterns change continuously. Practitioners should treat trust as a session property, not a login event.

Edge systems expose the limits of centralised identity design. SSO and core IAM platforms do not reach every specialised system, vendor application, or trackside workflow. That creates governance gaps where compensating controls become the real enforcement layer. The practical takeaway is to map the exceptions first, because that is where identity control fails in production.

Empathy by design is an access governance pattern, not a usability slogan. The article shows that controls were tested against actual user workflows before rollout, which is how friction gets reduced without weakening protection. Identity programmes that ignore workflow reality create shadow bypasses, support overhead, and policy drift. Security teams should measure whether controls survive real use, not just policy review.

Formula 1 shows why identity maturity is operational, not theoretical. A high-speed environment forces continuous balancing of access, performance, and resilience, which is exactly what modern identity programmes must do. The lesson is not that racing is unique, but that every fast-moving enterprise now faces similar conditions across cloud, endpoint, and third-party access. Practitioners should build identity controls that can move with the business.

Context-aware access is becoming the baseline for zero trust. The same organisation expects a consistent experience across campus and remote work, but the trust decision has to vary based on evidence. That aligns with ZT-NIST-207 and NIST-CSF thinking: verify continuously, minimise implicit trust, and keep the access decision tied to conditions rather than assumptions. Teams should re-evaluate any policy that still treats first authentication as the final decision.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Context-aware access only works when identity governance extends beyond people, so the next step is to study NHI Lifecycle Management Guide for lifecycle controls that keep machine access accountable.

What this signals

Context-aware access will become the default expectation, but only if identity teams can operationalise it beyond humans. The lesson from fast-moving environments is that authentication alone is no longer enough. As access decisions increasingly depend on device posture, location, and workflow context, the governance challenge shifts toward continuous verification across every identity type, including machine access and vendor-managed pathways.

Identity programmes need a new concept of exception debt: every system that sits outside the central policy stack adds a permanent governance liability unless it is explicitly mapped and controlled. That is where SSO coverage ends and operational reality begins, so exception inventories now matter as much as policy design.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, the same basic lesson applies to high-speed operations: identity risk concentrates in the places central controls do not reach.

For practitioners

• Map access decisions to context signals Use device posture, network location, software state, and session risk to shape access decisions after login, not just at authentication. This reduces over-trust in accounts that are technically valid but operationally unsafe.
• Inventory every edge system and exception path Document specialised tools, vendor platforms, and other systems that sit outside your core SSO and policy stack. Assign a compensating control for each one so no workflow depends on an ungoverned exception.
• Test controls against real workflows before rollout Run policy and endpoint changes through live-user simulations, then measure delay, failure rate, and support escalation. If a control creates friction without reducing risk, refine it before production use.
• Treat resilience as a layered identity design problem Combine segmentation, encryption, monitoring, and incident response so a single failure does not expose all access paths. Rehearse the seams between controls, especially where third-party systems connect to internal workflows.

Key takeaways

• Fast-moving organisations need access decisions that respond to context, not just authentication, or they will grant too much trust too early.
• Edge systems, vendor tools, and other exceptions are where identity governance usually breaks down, so those paths need explicit ownership and compensating controls.
• Security controls must be tested against real workflow friction before rollout, because unusable controls are the ones most likely to be bypassed.

Key terms

• Context-aware access: An access model that evaluates more than identity at login, including device posture, location, network, and session behaviour. It tightens or expands trust as conditions change, which makes it more suitable for distributed work than a one-time yes-or-no decision.
• Compensating control: A secondary safeguard used when the primary control does not reach a system, workflow, or platform. In identity programmes, compensating controls are often the difference between an acknowledged exception and an unmanaged security gap.
• Exception path: A workflow, system, or platform that sits outside the main identity and access stack. These paths often carry elevated operational risk because central policy enforcement, logging, or review does not apply in the same way it does to core systems.
• Session trust: The amount of confidence granted after authentication based on what the session looks like in real time. It reflects device health, location, and behavioural context, and it can change during the session if risk signals change.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Password: Oracle Red Bull Racing balances speed and security with 1Password. Read the original.