In the last post, I talked about the host management system. Everything you would expect from an RMM tool, but done right. I mentioned that user and group management connects to something bigger. This is that something.
Small Things That Make Sense
Part of the Cadres philosophy is that all features are fully integrated. Using any tool in the platform should be as frictionless as possible. That sounds obvious, but the industry has a terrible track record here. Most platforms bolt features together after the fact and it shows in every click.
When I was designing the remote control tool, I hit a practical problem. I wanted to connect to a host using a different set of credentials than what the Cadres agent was running under. The agent runs as SYSTEM or root. That is fine for executing jobs. But when I am remoting into a server, I might need to connect as a domain admin, a service account, or a specific local user. I do not want to type those credentials every time, and I definitely do not want them sitting in a spreadsheet or a shared password manager that everyone on the team can browse.
That problem sparked the idea. What if I could just check out the credentials on the fly while connecting? No context switching. No copy-pasting from another tool. Just select the credential, authenticate, and you are in.
From Credential Checkout to a Full Vault
Once you start down that road, the design expands fast. If I am storing credentials for remote sessions, I need a way to organize them. If I am organizing them, I need a way to control who can access what. If I am controlling access, I might as well build it properly.
So we built vaults and secrets. Vaults are containers that let operators organize and protect groups of credentials. You can scope a vault to a team, a customer, or a project. Access is controlled through the same RBAC system that governs everything else in the platform. No separate permission model. No “admin password for the password tool” nonsense.
A secret can be a username and password pair, an SSH key, an SNMP community string, an API key, or any other credential that needs to live somewhere secure. Everything is encrypted at rest. Access is audited. Every checkout is logged with who, when, and why.
Zero-Knowledge Credentials
When we added user and group management to the host management system, a natural extension appeared. What if you could migrate a local account directly into the vault?
Here is why that matters. When you migrate an account to the vault, the credential becomes zero-knowledge. The password is changed during the check-in process. Nobody knows what it is. Not the operator, not the admin, not even the person who created the account. The password exists only inside the vault.
When someone checks out the credential, they get the current password for the duration of their session. When they check it back in, the system rotates the password automatically. Nobody knows the new value. The next person who needs access gets a fresh checkout and the cycle repeats. Break-glass sessions always force a rotation on check-in, no exceptions.
This is not some theoretical security posture improvement. This is a practical solution to a real problem. Shared admin passwords that never change. Service accounts with passwords written on sticky notes. “Break glass” credentials that half the team knows from memory. All of that goes away.
One Vault for Everything
The vault is not just for host credentials. SNMP community strings that the network discovery engine uses? They live in the vault. API keys for third-party integrations? Vault. Service account credentials that automation workflows need? Vault.
It is a one-stop solution for any secret that needs to be stored for use across the platform. When the workflow engine needs credentials to execute a task, it checks them out programmatically with the same audit trail as a human operator. When the SNMP poller needs community strings to walk a switch, it pulls them from the vault. Everything goes through the same system, the same encryption, the same access controls, the same logs.
Why This Had to Be Built In
You could argue that dedicated PAM products already exist. That is true. The problem is that they are separate systems. You need connectors, API integrations, sync jobs, and often a dedicated team to manage them. For a large enterprise with a mature PAM program, that can work.
For everyone else, it does not. Many teams are lean and do not have the bandwidth to operate a separate PAM system alongside their RMM, their ticketing system, their monitoring, and their compliance tools. The credentials end up in a password manager that everyone shares, or worse, in a spreadsheet.
Building PAM into the platform means it is there from day one. No integration project. No additional licensing. No separate console to train people on. The same operator who is managing hosts and running scripts already has access to vaults scoped to their role. The friction is so low that people actually use it.
What Comes Next
The vault and the workflow engine are two pieces that connect in an important way. When you combine managed credentials with automated workflows and approval gates, you start to eliminate the scenarios where humans need standing access to anything. That intersection is where the platform really starts to show its value.
If the idea of managing fewer agents, fewer tools, and fewer shared passwords sounds appealing, start a trial.