Q‑Tel combines hardware-bound identity, end-to-end encrypted communication and a protected vault. The enterprise platform with its own instance is being built on this foundation.
Available (pilot) In pilot operation today: iOS (TestFlight) and Android.
From identity to confirmed action: every layer has a defined role in the security model.
Cryptographic identity instead of a phone number.
Keys in the device’s security chip.
End-to-end encrypted chats and calls.
Vault with its own code, key only on the device.
Approval with a dedicated key instead of a mere tap.
Standard platforms bundle communication, identity, administration and infrastructure. Q‑Tel separates these areas into controllable, connected layers.
Identity, approvals, communication and vault each have their own single-purpose keys.
The server relays, verifies signatures and delivers – it never sees content or private keys.
Communication, files and confirmed approvals in one trust model.
A factual look at operating model and responsibility – not at blanket security promises.
Model B describes Q‑Tel’s target for organisations. Today Q‑Tel runs as a shared pilot environment.
Every building block with its status – what you can use today, what is in preparation and what is a goal.
Account without phone number or e-mail. Device keys are created in the Secure Enclave or Android Keystore and never leave the device.
Limitation: StrongBox only on Android devices with a dedicated security chip; otherwise Keystore (TEE).
Available (pilot)End-to-end encrypted one-to-one and group chats. Group changes live in a signed chain that every member verifies itself. Delivery and read status.
Limitation: Delivery receipts in one-to-one chats only; on iPhones once Q-Tel is opened.
Available (pilot)Encrypted voice and video calls that check the stored contact key before connecting.
Limitation: Call wake-up on Android uses Google services; without them calls only ring while the app is open.
Available (pilot)Locally encrypted storage for photos, documents and notes with its own code. The key exists only on the device.
Limitation: No versioning, folders or roles – single-user storage.
Available (pilot)Send files from the vault encrypted to one contact – for that contact’s verified receiving key.
Limitation: No approval workflows, no multi-recipient packages.
Available (pilot)Sensitive actions are confirmed with a separate, biometrically protected approval key – the server can verify signatures but cannot forge them.
Available (pilot)Make attributes and credentials verifiable with as little disclosure of personal data as possible.
Architecture goalAnswers and summaries on your own knowledge base within your own environment.
Architecture goalRoles, policies and approvals for organisations with traceable workflows.
Architecture goalFor particularly sensitive communication, Q‑Tel is to be provided on specially configured, hardened devices.
Already today Q‑Tel uses the Secure Enclave on iPhones and the hardware-backed keystore on Android – with StrongBox where the device has a dedicated security chip.
Restrictive system configuration with a smaller attack surface.
Trust anchor from system start, depending on hardware platform.
Device state as a signal for access decisions.
Only defined applications in each security profile.
Camera, USB, Bluetooth and NFC restrictable per profile; on selected hardware individual sensors can be physically removed.
Updates only through the separate release chain.
Revoke access specifically when a device is lost.
Profiles by organisation, role and protection needs.
Device image illustrative. The Secure Device programme is an architecture goal; available measures depend on hardware platform, security profile and the specific deployment.
Private AI is to help find answers, summarise documents and prepare tasks on your own knowledge base – within your own environment.
The documents cover three relevant topics. I can structure the results by source and mark open points for the next approval.
Own knowledge baseWhat is implemented today, what is in preparation and what is a goal are never presented as the same.
In the current app on iOS and Android.
Ready before public launch, or built and not yet shipped everywhere.
Direction of the platform – explicitly not promised today.
At launch Q‑Tel runs on a distributed infrastructure with a standby site and controlled, safeguarded failover. Until then the pilot runs in one data centre in Germany.
Identity, communication and vault in one defined trust model.
AT LAUNCH: SEVERAL SITES
Pilot operation in one data centre in Germany; servers see no content.
Available (pilot)Dedicated Q‑Tel servers at several sites, encrypted backups with tested restore, separate release chain.
At launchMore sites and dedicated instances for organisations as needed.
Architecture goalServer image illustrative. Several sites are planned for launch and not yet in operation today.
Three planned tiers. We are looking for pilot organisations to shape the model with us.
The private foundation for controlled collaboration.
More control over devices and approvals.
Extends security to the entire device.
Talk to us about how Q‑Tel can fit your organisation – as a pilot or for the enterprise platform.
