Security and trust
You hold the keys to your customers. We help you guard them.
An MSP platform can reach every machine and tenant you look after. Here is how Tenvara is built to deserve that access, in plain terms.
Access and sign-in
- Two-factor and passkeys
- Local accounts use TOTP two-factor or passkeys, and admins can make two-factor mandatory.
- New sign-in alerts
- A sign-in from a new device or place is emailed to the person, with a "This wasn't me" link that ends the session.
- Single sign-on
- Entra ID, Google Workspace, any OpenID Connect provider, or SAML 2.0, with group to role mapping and domain enforcement.
- Break-glass access
- Local sign-in stays available to a named admin when single sign-on is required for everyone else.
- Roles and permissions
- Role templates for every job in an MSP, with permissions per module and action, staff scoped by customer, and costs, pay rates and personal details hidden from roles that do not need them.
- Sessions and networks
- See every signed-in session, sign out everywhere, time out idle sessions, limit roles to IP ranges, and ask for sign-in again before sensitive changes.
- Approvals for risky actions
- Scripts on many devices, software to a whole customer, credit notes, vault exports and remote sessions to sensitive devices can be set to need a second person.
- Scoped API tokens
- One place for API tokens, each with its own scopes and expiry.
- A switch for each sensitive action
- Running scripts, revealing credentials, restoring backups, remote control, exports, bulk changes and Microsoft 365 changes each have a role switch, enforced on every route in, automation and AI included.
- Tokens that end for good
- API, MCP and OAuth tokens end when an account is turned off, signed out everywhere or reset, and making or widening a token asks you to confirm it is you.
- Know who is calling
- Before a password or MFA reset, check the caller with a code to the details already on file, a callback, their manager's approval, a prompt in the portal or a number they pick on their own Windows computer. A policy per customer can block the reset until they are verified, and every check is audited.
Isolation, audit and privacy
- Row-level security by customer
- A technician scoped to some customers sees only those customers, enforced in the database itself, for every customer table, report, search and notification.
- A tamper-evident audit log
- Sign-ins, settings, permissions, exports, remote sessions, scripts, credentials and Microsoft 365 actions in one hash-chained log, checked every day.
- Retention you set
- Keep each kind of data for as long as you choose, with legal holds where something must be kept, and security logs for up to 10 years.
- Privacy requests
- Handle GDPR access and erasure requests from the app: a ZIP export of a person's data, and erasure by anonymising so your records still add up.
- Erase a customer, with a certificate
- An administrator can erase a customer for good: everything it owns in every store, keeping only invoices and credit notes. You see what will go first, a legal hold stops it, and a numbered certificate records it.
- Decisions on record
- An accepted risk, a hardening exception or an AI tool can need a signed customer sign-off before it takes effect, with a PDF certificate of the text as signed and the audit trail.
- Limited folders stay limited
- A documentation folder limited to named people stays limited everywhere: lists, search, previews, history, comments, shared files, reports, the portal and the AI's answers. Administrators-only credentials stay hidden in the same places.
Data and the platform
- Encrypted secrets
- Credentials, TOTP seeds, licence keys and integration tokens are encrypted at rest and only decrypted when used or revealed.
- Every reveal audited
- Revealing a credential records who, what and when. Nothing secret is shown by default.
- Encryption in transit
- Every connection, from the browser and from the agent, uses TLS.
- Your data, your location
- Self-hosted installs keep everything on your infrastructure. Hosted instances each have their own database.
- A strict content security policy
- The app, the portal and the chat widget run under a nonce-based Content-Security-Policy with no inline scripts, with HSTS and tight cross-origin rules.
- Requests that stay outside
- Anything the server fetches for you goes through one client that refuses internal and cloud metadata addresses and checks every redirect again.
- Hardened images
- Release images are rebuilt on updated bases with no build tools in them, the web front door runs as non-root, and downloads are pinned by checksum.
- Internal services kept apart
- Each internal service holds only its own token, so the mail receiver that faces the internet can speak for nothing else.
The agent
- Signed builds
- Windows and macOS agents are code signed, and updates are verified before they install.
- Self-update with rollback
- A failed update rolls back rather than leaving a device unmanaged.
- Scripts run signed
- Every script the Windows agent runs is a signed file, checked before each run, never an inline or encoded command, so security software can tell the agent's work from an attack.
- Signed remote control requests
- A remote session opens only from a request signed by your server with the key the agent learnt at enrolment, and the consent level is part of what is signed.
- Agents pin their server
- Each agent pins the key of the certificate your server presents, with a signed way to rotate it, and refuses anyone in the middle holding an otherwise valid certificate.
- One connection
- Every module talks to the server through the one authenticated agent connection.
- Tamper protection
- Removing the agent needs a per-customer uninstall token, a stopped agent restarts, and stops and removals raise alerts.
- Updates in rings
- New agent versions go to a pilot ring first and halt on any failure, never during a remote session or a backup.
- Consent people can read
- When a technician asks to remote in and your policy asks the person first, the window says who is asking, with their photo, what they will be able to do and how long is left. Decline is the default, so pressing Enter never lets anyone in.
- Gone means gone
- Deleting a device removes its agent, at once or when it next checks in, and only a fresh enrolment token brings it back. Keeping the agent is a choice you make on purpose.
Your customers' devices, secrets and backups
- LAPS and BitLocker behind the vault
- With the Intune permissions consented, LAPS passwords are revealed through the vault's permission and audit, like any other credential. BitLocker recovery keys are too, and the agent collects every encrypted volume's key into the vault by itself.
- Immutable backups
- Backups can be written with S3 Object Lock to your own bucket, locked against deletion, even by an administrator, until their retention ends.
- Two people to delete
- Deleting backups is a soft delete that needs a second administrator to approve, and so do shortening retention and weakening an Object Lock.
- Scanned before restore
- Restores can be scanned with ClamAV and known-bad hashes before anything comes back.
- A recovery copy of the backup key
- Download the backup encryption key sealed with a passphrase you choose, after an authenticator code and a second administrator's approval, then check that your copy opens.
- Other remote tools found
- The agent finds other remote access and RMM tools on your customers' devices, so you allow the ones you expect and remove the rest.
- Vulnerabilities in the order to fix them
- Findings carry the operating system vendor's own rating and fix state, are prioritised by whether a fix exists and whether attackers use them, and the To do list groups them by the one update that fixes them.
- A policy for the browser extension
- Set and lock how the extension saves, fills and locks for your whole team. A customer's own people follow that customer's policy, set by you or by a contact you allow in the portal, and a locked setting says it is set by their organisation.
AI and third parties
- Off by default
- AI features do nothing until you add your own Anthropic API key.
- AI assistants as the person
- Assistants connected through the MCP server act with the permissions and customers of the person who connected them, read only unless allowed more, with every call audited.
- Read-only unless approved
- The assistant runs read-only checks. Anything that changes a device needs a technician to approve it.
- Listed and logged
- Settings lists exactly what is sent to the model, and every AI call and result is logged on the ticket.
- Per-customer opt-out
- Switch AI off for any customer who prefers to go without it.
- Within each person's level
- AI and MCP tools work within the role of the person using them, and the activity log shows each person their own questions.
Reporting a vulnerability
If you think you have found a security problem in Tenvara, email security@tenvara.io with the details and how to reproduce it. We will acknowledge it, keep you updated, and credit you if you would like. Please give us a reasonable time to fix it before telling anyone else, and do not access data that is not yours.
Data protection
For hosted instances we act as your processor under UK GDPR and EU GDPR. Our data processing agreement sets out what we do with the data and how we protect it.
Security questionnaire to fill in?
Send it over. We'll answer it properly rather than pointing you at a badge.