An ARM control-flow feature that restricts indirect branches to approved landing points marked by the compiler. It is designed to reduce gadget abuse by ensuring branch instructions reach valid entry opcodes. In combination with Pointer Authentication, it raises the difficulty of redirecting execution after a memory corruption bug.
Expanded Definition
Branch Target Identification, or BTI, is an ARMv8.5-A control-flow hardening feature that narrows where indirect branches may legally land. The compiler marks approved entry points, and the processor checks that the branch target matches those landing pads before allowing execution to continue. In practice, BTI is part of a broader control-flow integrity story, not a standalone fix for memory safety bugs.
Its boundary is important. BTI does not stop an attacker from triggering a memory corruption flaw, and it does not validate data, permissions, or logic flow. It specifically makes some redirect-to-gadget techniques less reliable by removing many usable landing sites. That is why BTI is usually discussed alongside pointer authentication and other mitigation layers rather than as a complete defence. The ARM architecture documentation is the most direct authority for the mechanism itself, and practitioners should read BTI in that hardware context rather than as a generic application security term.
Examples and Use Cases
BTI appears wherever software is compiled for ARM targets that support the feature and where the build chain enables it. Typical use cases include:
- Mobile operating systems enabling BTI for core platform binaries to raise the cost of control-flow hijacking after a memory corruption bug.
- Browser engines and sandboxed runtime components using BTI to reduce the number of viable gadgets available to an attacker.
- High-value native services compiled with BTI and pointer authentication together so that both branch landing and return-address tampering are harder.
- Firmware or embedded software adopting BTI where the platform can afford the compatibility and performance trade-off of stronger control-flow checks.
The main implementation trade-off is compatibility. Code that depends on unconventional indirect branch behaviour, JIT-generated code, or legacy binaries may need changes before BTI can be used safely. That makes build-system support and binary hygiene part of the practical deployment story, not an afterthought.
Security Implications
When BTI is absent or disabled, indirect branches can be redirected to a much larger set of code locations, which increases the attacker’s search space for gadget-based exploitation. When BTI is present but inconsistently applied, the protection becomes uneven, and mixed libraries can create weak spots where one unprotected module undermines the value of the rest of the stack.
The failure mechanism is straightforward: a memory corruption bug gives the attacker partial control of program flow, and the absence of a branch target check allows that control to be steered into instruction sequences that were never intended to be callable. The consequence is often not immediate full compromise, but a substantial reduction in exploit difficulty, especially in combination with information disclosure or a second memory-safety weakness. Practitioners should treat BTI as a hardening layer that narrows exploit paths, not as proof that code is safe.
Domain and Governance Relevance
BTI belongs primarily to software hardening and platform security, but it matters in governance because it changes what “secure by default” means for compiled ARM software. For organizations that ship or rely on ARM binaries, BTI becomes part of the secure build baseline, the platform support matrix, and the assurance story for code that is expected to resist control-flow hijack attempts.
The identity and NHI lens is only indirect here. BTI is not about identities themselves, but it can materially affect the resilience of agents, services, and other software components that run with privileged access or long-lived execution authority. In those environments, stronger control-flow constraints reduce the chance that a single memory corruption bug becomes a durable foothold. For that reason, BTI is best governed as part of platform hardening and secure compilation policy rather than as an isolated compiler flag.
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 and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16.6 — Software Code Execution Prevention | BTI hardens indirect control-flow execution on ARM binaries. |
| 4.1 — Establish and Maintain a Secure Configuration Process | BTI deployment depends on consistent compiler and platform configuration. | |
| Recommendation — Enable code-execution prevention features to reduce gadget-based exploitation paths. Standardise secure compiler settings so mitigation flags are applied consistently. | ||
| MITRE ATT&CK | T1055 — Process Injection | BTI raises the difficulty of hijacking execution after memory corruption. |
| Recommendation — Hunt for execution-hijack techniques and validate whether mitigations block them. | ||
| NIST CSF 2.0 | PR.IP-1 — Baseline Configuration | BTI belongs in secure build and platform hardening baselines. |
| PR.PT-3 — Least Functionality | BTI reduces unnecessary executable landing points for indirect branches. | |
| Recommendation — Define hardened build baselines that require control-flow protections where supported. Restrict executable pathways to the minimum needed for trusted code paths. | ||
Related resources from NHI Mgmt Group
- When should teams move from target-phase controls to advanced OT Zero Trust controls?
- Should organisations allow pull_request_target for automated dependency workflows?
- What do teams get wrong about force-pushing a cleaned branch?
- What breaks when network segmentation is based on old branch-office assumptions?
