Bluetooth Core 6.3 release date

The Bluetooth SIG adopted Bluetooth Core Specification 6.3 on May 5, 2026. The SIG published its release overview on May 6. If “release date” means the specification’s official version date, use May 5; May 6 is the announcement date. Neither date proves that a shipping controller supports the new features.

Milestone Date What it establishes What it does not establish
Specification adopted May 5, 2026 Bluetooth Core 6.3 became the current adopted Core version Controller, host stack, or product support
SIG release overview published May 6, 2026 The public feature summary became available Normative implementation requirements
Controller and stack availability Vendor-specific A named implementation exposes selected 6.3 capabilities End-product qualification or measured performance
Product availability Product-specific A shipping configuration implements and qualifies claimed features Support in other SKUs, revisions, or regions

This distinction matters when a roadmap, procurement sheet, or search result uses “released” without naming the milestone. Record the adopted specification date separately from silicon sampling, stack support, qualification, and the date a product actually ships.

What changed in Core 6.3

The SIG’s release material describes improvements in ranging precision, interface capacity, and radio efficiency. Two highlighted Channel Sounding changes are Inline PCT Transfer and PHY-specific round-trip-time accuracy reporting.

Inline PCT Transfer allows a Channel Sounding reflector to transfer phase-aligned tones directly into hardware. The SIG says this can reduce unnecessary reporting overhead and improve the efficiency of the procedure. PHY-specific RTT Accuracy lets a device report RTT accuracy separately for each PHY instead of using one value across PHYs.

The release also contains host-controller interface and radio-efficiency changes. Their exact normative requirements belong in the Core Specification and related qualification material, not in a summary article.

What the changes mean for a product

Channel Sounding products need an honest chain from radio capability to application claim. More precise or better-described inputs can improve a ranging pipeline, but enclosure design, antenna geometry, multipath, calibration, implementation, and threat model still determine measured product behavior.

PHY-specific accuracy reporting is useful because a host can reason from a more accurate statement of controller capability. It does not automatically calibrate a system or guarantee distance accuracy in a target environment. Inline transfer may change controller and host implementation choices, but the benefit must be measured on the selected silicon.

Interface-capacity changes matter to controller, host-stack, and test-tool teams even when an end user never sees a new Bluetooth feature. Compatibility across host and controller versions should remain explicit.

Bluetooth controller and host-stack vendors need to assess implementation and qualification changes. Product teams using Channel Sounding should review silicon roadmaps, security assumptions, accuracy models, and test plans. Device makers that do not use the affected capabilities may only need normal specification and qualification tracking.

Test labs and qualification owners need the adopted specification, changes document, test case references, and applicable program rules. Marketing teams should not turn a Core version number into an unsupported ranging claim.

Evidence to collect before adoption

Identify the exact 6.3 features relevant to the product rather than adopting a version label as a goal. Ask silicon and stack vendors which features are implemented, in which revisions, and with what qualification status. Keep host, controller, firmware, and test-tool compatibility in the release matrix.

For Channel Sounding, repeat accuracy and threat testing in the final enclosure and deployment environment. Record PHY, antenna configuration, calibration, environmental conditions, and the controller-reported accuracy inputs. Test degraded and adversarial conditions rather than reporting only a clean lab result.

Review whether new interface behavior changes buffers, event handling, power, or failure recovery. Update product claims only after measurements on shipping-equivalent hardware.

Do not replace working silicon merely to advertise Core 6.3. Do not assume an existing controller gains new features through a host update. Do not publish a distance-accuracy number from the specification announcement. Do not skip qualification or regulatory review because the change appears internal.

Products unrelated to Channel Sounding or the changed interfaces can track vendor support through their normal maintenance process rather than creating an urgent migration.

Use the broader Bluetooth Low Energy engineering reference to place Core 6.3 inside the GATT, profile, commissioning, and gateway decisions that a product still has to make.

Common Bluetooth 6.3 questions

Is Bluetooth 6.3 available now?

The specification is adopted and available from the Bluetooth SIG. Feature availability in a controller, host stack, operating system, test tool, or shipping product is a separate claim that must name the implementation and version.

Does Bluetooth 6.3 require new hardware?

Do not assume either answer for a product. A host update cannot create radio or controller capabilities that the silicon does not implement. Some interface behavior may be delivered in firmware or stack updates, while radio features may depend on controller hardware and vendor support. Use the vendor’s feature and qualification matrix.

Should a product wait for Bluetooth 6.3?

Wait only when a specific 6.3 capability materially changes a documented requirement and the chosen supply chain can support it. A version number alone is not a product requirement. Teams that do not need the changed capabilities should continue normal component, qualification, security, and lifecycle evaluation.

When to revisit the decision

Watch the Bluetooth SIG qualification resources and the “changes since previous version” material, then track controller and stack release notes from selected suppliers. For a shipping product, maintain a matrix of implemented Core features rather than a single “Bluetooth 6.3” boolean. Revisit this signal when production silicon, test coverage, or qualification guidance changes the decision—not whenever a marketing page repeats the version number.

The version, date, and summarized features are facts from the Bluetooth SIG. Product implications, risk questions, and recommended tests are IoT 01 analysis. Any claim about a particular chipset requires that vendor’s current documentation and product measurements, which are outside this signal.