What privileged access management is for

This article is for someone who has been told their business needs 'privileged access management' and does not know what the phrase means. It assumes no prior knowledge. Nothing in it is a product tour; it is an explanation of a real problem you almost certainly have, followed by an honest account of how much of it Qorionix currently solves.

It also carries a warning worth reading before you invest a week in this. Of the capabilities in Qorionix, privileged access is the one that asks the most of you before it gives anything back, and it is the one we suggest you adopt last. The reason is at the end, and it is not a sales reason.

The accounts that can do anything

Every business runs on a small number of accounts that are not like the others. The administrator account on the domain controller. The root login on the Linux box that runs the accounting system. The sa login on the SQL Server database. The account that signs in to the firewall. The AWS key that pays for the cloud. In a company of forty people there might be fifteen of them.

What makes them different is not that they are technical. It is the blast radius. An ordinary account, in the wrong hands, damages one person's work. One of these, in the wrong hands, damages all of it — including the backups, which is how a bad week becomes an existential one.

Four things are true of these accounts in nearly every organisation that has never done anything deliberate about them:

• The password is shared. It lives in a note in a shared password manager, in a spreadsheet, in a WhatsApp message from 2023, or in the head of the person who set the server up. Three or four people know it. Nobody has written down who.
• Nobody knows how old it is. Ask when the domain administrator password last changed and the honest answer is a shrug. If it was set when the server was installed, it is as old as the server.
• Nobody can say who used it. The logs on the server record that administrator signed in. They do not record which of your four people that was, or why.
• When someone leaves, nothing changes. Their own account gets disabled on their last day, because that is a task with an owner. The shared administrator password they also knew does not change, because changing it is a project — something might break, and nobody is sure what.

That fourth one is the expensive one. A former employee, or a former contractor, or the IT company you stopped using in March, still holds a working key to the most important machine you own. Not through malice in most cases — through nobody having a mechanism.

The four things a privileged access system does

Everything sold under the name 'PAM' is some combination of four ideas. They are worth understanding separately, because they solve different halves of the problem and you can adopt them in stages.

A vault

One encrypted store for privileged secrets, in place of the spreadsheet. The value is not secrecy from you — you are allowed to know your own passwords. The value is that there is exactly one place, and that place records who added the secret, when it last changed, and which machine it opens. A vault turns 'we think Dave has it' into a record. See The credential vault.

Rotation

The system changes the password on the target machine on a schedule, and stores the new one. This is what makes the answer to 'how old is this password' a number rather than a shrug, and it is what makes a leaver stop mattering: whatever they memorised expires on its own. See Credential rotation overview.

Proxying, or session brokering

Instead of handing a person the password, Qorionix opens the connection to the server itself, supplies the password to the server, and gives the person the finished connection. They do their work as the administrator without ever learning the administrator's password. See Proxied SSH sessions.

Approval

Before privileged access is granted, someone asks for it with a written reason, and a named person approves. The approval is single-use, so an approval granted for Tuesday's maintenance does not silently become standing access. See Access requests and approvals.

Of the four, proxying is the one that changes the shape of the problem rather than managing it. A password that was never given to a human being cannot be written on a sticky note, reused on a personal account, or carried to a next employer. Everything else on the list reduces the damage of a shared secret; proxying removes the sharing.

The vault is nevertheless first, because the other three need it. Rotation needs somewhere to put the new password. Proxying needs somewhere to read the password from. Approval needs something to approve access to.

What this module asks of you that the others do not

The posture assessment needs one consent in Microsoft 365 and then works. Log collection needs a connector switched on. The endpoint sensor needs installing, which is a real task, but a repetitive one.

Privileged access needs an inventory, and you almost certainly do not have one. For each privileged account, Qorionix has to be told four things: which machine it is on, what kind of machine that is, what the account is called, and what its password is today. It cannot infer any of this from your Microsoft 365 tenant, because these accounts do not live there. They live on your servers, your switches, your databases and your cloud provider — the places nobody has enumerated since the day they were set up.

Qorionix has a discovery scan that will find candidate privileged accounts on machines you point it at, and it shortens the job considerably — see Discovering privileged accounts. It does not remove the job. Something has to decide which of the accounts it found matter, and that something is a person who understands your business.

What is shipped today, and what is not

The table below is the honest state of the module as of this release. We publish it because the alternative — you discovering the gaps during a maintenance window — costs you more than it costs us to write down.

Three of those rows deserve a sentence in plain terms rather than a table cell.

The application-to-application path does not work. If your hope was to take the hard-coded passwords out of your own scripts and have them fetch a secret from Qorionix at run time, that is not available. The path returns the literal placeholder redacted-see-docs where the secret should be. Leave your scripts as they are for now and use the vault for human-held secrets only; we will say plainly in the release notes when this changes.

Entra ID service principal rotation has never met a real Microsoft tenant. The code is present, wired and exercised against a simulated Graph API. That is not the same as evidence. If you want it, ask us and treat the first rotation as a supervised experiment on an application you can afford to break — details in Rotating cloud credentials.

There is no retry. A rotation that fails is recorded as failed with a reason, and then simply waits for its next scheduled run — thirty days later, on the default interval. This matters because it means a failing rotation is something you have to notice, not something that resolves itself. The vault list shows the failure and its reason on the credential, so noticing it takes a glance rather than an investigation.

Why we suggest you adopt it last

Two reasons, and both of them are about you rather than about the software.

The first is the ratio of effort to return. The posture assessment gives you a report naming your own administrators about ten minutes after you consent. Privileged access gives you nothing until you have enumerated your privileged accounts, and enumerating them is real work that no software can do on your behalf. Doing the ten-minute thing first is not laziness; it is the correct order.

The second is that this is the only module that writes to your production systems in a way that can lock you out. A posture check reads. A detection rule reads. A rotation changes the password on your domain controller. Done well, that is the single most valuable security control in this list. Done to an account you did not realise a scheduled task was using, it stops the scheduled task at three in the morning. Every rotation article in this section names the things that break, because that is the part we can genuinely help with.

What to do next

If you have read this far and still want the module, the sequence below is the shortest honest path to value.

1. Make the inventory on paper. Machines, then the accounts on each one that can change it.
2. Register your targets — one row per machine, and run the connection test on each. The test tells you whether Qorionix can reach it before you trust anything else.
3. Put the secrets in the vault — and read what happens if the encryption key is lost, because that part is unforgiving.
4. Turn on rotation for one credential — on a machine you can afford to have a bad afternoon with. Not the domain controller first.