SECURITY
What we protect, and how
UPDATED AUGUST 17, 2026
Most security pages describe the strongest thing a product does and let you assume it applies everywhere. ManagedBit has two planes with two genuinely different promises, and telling them apart is the most useful thing this page can do for you. So the boundary is drawn first, and what we have not built yet is listed at the bottom — by name.
The two planes
SESSION PLANE
End-to-end encrypted
Remote control, terminal, file transfer and clipboard. We broker the session; we never hold its keys or its plaintext.
- Keys are established between your technician and the endpoint.
- Our relay forwards ciphertext and can read none of it.
- This holds against any access to our infrastructure — including ours.
MANAGEMENT PLANE
Access-controlled
Fleet inventory, script output and remediation logs. These are readable by the service that stores them, and protected by controls rather than by mathematics.
- Stored as plaintext at rest today.
- Bounded by database row-level security, short retention and purge.
- No vendor employee has a console path to tenant data.
The session plane's guarantee is cryptographic. The management plane's is architectural. Both are real; they are not the same strength, and we will not describe them in the same words.
What we deliberately don’t say
You will not find us claiming to be blind to your management-plane data because of row-level security. Row-level security is authorization — it decides who may read a row. It is not encryption and it does not make us incapable of reading one. A vendor who conflates the two is describing a policy and calling it a proof.
What is true today: our staff accounts carry no visibility into tenant data by construction — they hold platform-administration permissions only, and an automated test fails the build if that ever changes. That is a property of our code, which we maintain and you can hold us to. It is not the same as being unable to look, and the fix that would make it the same — customer-held encryption keys — is designed and not yet built. It is listed below with everything else we owe.
No covert access
A remote-access tool that can watch quietly is a surveillance tool. Two mechanisms make that structurally hard rather than merely against policy:
- A presence indicator that isn’t optional. Every session raises an on-screen banner on the endpoint, across every channel — screen, terminal, files, clipboard. It is not a setting an administrator can quietly disable, and if the banner cannot be shown the session ends.
- Hash-chained audit on both sides. The endpoint keeps its own signed record of every session, and so does the control plane.
Two words matter here, and we use them precisely:
- Tamper-detecting means edits and reordering are evident — a hash chain gives you this. It does not stop someone who can rewrite the whole record from recomputing a perfect one.
- Tamper-evident means the record’s trust root sits outside the record, so rewriting it requires forging a signature from a key the rewriter does not hold.
Both of our audit chains now meet the second bar. The endpoint’s chain is certified by that machine’s enrolled hardware identity and its position is witnessed by the control plane, so a truncated or replaced log is evident by comparison. The control plane’s own chain is signed under a dedicated audit key — one that signs nothing else, so no single key can both author an event and vouch for it.
The precise bound, because a security page that only states its strengths is doing the thing this page exists to avoid: the control plane signs its chain at intervals rather than signing every record, so records written since the most recent signature are chained but not yet signed. That narrows the window in which history could be rewritten to the time since the last checkpoint — it does not eliminate it. The same applies at the endpoint between the moments its position is witnessed.
How the platform is built
- Separated signing keys. Nine control keys, each with one job — session grants, technician directory, branding, presence policy, inventory, monitoring, deployment, catalog, and audit. The split is the point: compromising one key is not enough to complete an attack, because the steps require different keys.
- We don’t invent cryptography. We use vetted, published protocols and implementations rather than designing our own primitives.
- Memory-safe by construction. The platform is written in Rust, and the small amount of unavoidable unsafe code is wrapped and reviewed rather than spread through the codebase.
- Fail closed. A security control whose precondition is missing refuses rather than warning and continuing. An unreadable policy file, an unconfigured identity provider or an absent flag stops the operation; it does not quietly permit it.
What we have not built yet
This is the part most security pages omit. Everything below is designed and specified but not shipped, and we would rather you learn it here than discover it later.
| CAPABILITY | STATUS | WHAT THAT MEANS TODAY |
|---|---|---|
| Customer-held encryption keys (BYOK/CMK) | DESIGNED | Management-plane data is protected by access control, not by keys you hold. This is the change that would make vendor-blindness a cryptographic claim. |
| Per-tenant encryption at rest | PLANNED | Inventory, script output and remediation logs are plaintext in our database, bounded by row-level security, retention limits and purge. |
| Session recording with customer-held recovery | DESIGNED | Recording is specified to keep recovery a customer capability rather than a vendor one. It is not available yet. |
An honest limit worth stating
Access to an endpoint is authorized by our control plane. An attacker who compromised a running control plane could therefore authorize a session — that is inherent to brokered access, and we would rather name it than imply otherwise. What that attacker could not do is make it invisible: the endpoint still raises its banner, still writes its own signed record, and the authorization still appears in an audit trail whose trust root is not the control plane's database. The design goal is not to claim a compromise is impossible. It is to ensure a compromise cannot be silent.
Reporting a vulnerability
Email security@managedbit.com. Tell us what you found and how to reproduce it. We will acknowledge your report, keep you updated while we investigate, and credit you if you would like to be credited. Please give us a reasonable opportunity to fix an issue before publishing it, and please don’t access data that isn’t yours while testing.
Status of this page
ManagedBit is in early access. This page describes the platform as built on the date above, and we update it when that changes — including when something moves off the “not built yet” list. If a claim here matters to your evaluation, ask us and we will show you the specifics.