A genuinely deployed product state
Core communication, device, cryptographic and operating workflows are deployed in production and bounded through the published release and evidence path.
This page connects product state, the security-update path, support boundaries, vulnerability handling and regulatory preparation. It publishes only what is genuinely committed today—and what deliberately remains open.
Core communication, device, cryptographic and operating workflows are deployed in production and bounded through the published release and evidence path.
Access, operating context, deployment and responsibilities are reviewed before use. The status is not an open self-service release.
Broad availability, general support commitments and standardised commercial terms are not automatically part of this product state.
Controlled Production Release does not mean an independent security audit, certification, regulatory approval or approval for classified information.
On 9 September 2026, the current product state was re-run through the internal cryptography, key-service, browser, multi-device, database, migration and downgrade verification path. The current run covers 308 counter-test mappings; the server-side migration rehearsal checks pending migrations in a disposable clone of the running data without transferring user data off the host. Infrastructure that cannot execute a check is recorded as open and never counted as passed.
Every release-relevant row in the internal conformance matrix is paired with a documented negative counter-test.
The real-Chrome path covers product flows including multi-device use, concurrency, recovery, revocation and local-data removal.
Single-use allocation was re-run against disposable PostgreSQL; the deliberately unsafe counter-case produced duplicate allocation and was detected.
Cryptography, key service, browser, multi-device, prekey concurrency, session locking, downgrade, server-side migration rehearsal, timestamps and schema alignment held in the combined current evidence.
No implied lifetime promises: version, update path and ownership must be reviewable for every deployment.
The current deployed state is identified through the Release Centre, signed runtime manifest and dated product evidence. Public website releases remain separate from product versions.
Security-relevant changes pass through the controlled build, test, release and rollback path. Specific timelines are committed only contractually or in a published advisory.
VENTEX currently publishes no blanket multi-version or long-term-support commitment. The applicable update path is agreed before deployment.
A general EOL calendar has not yet been published. Organisation-specific lifetime, migration and support commitments require an explicit agreement.
Observations enter triage through the published responsible-disclosure channel with the minimum necessary data.
Scope, reproducibility, impact, affected version and remaining uncertainty are assessed separately.
Remediation, negative tests, regression, migration impact and rollback together form the release gate.
Where public notice is required, the advisory connects impact, affected versions and remediation without overstated security guarantees.
The Cyber Resilience Act turns product security, vulnerability handling and update ownership into an ongoing product process. This public record is neither a declaration of conformity nor legal advice.
Public material enables preliminary review. Architecture, privacy, contract terms and support commitments must then be assessed for the individual organisation.