What Recording Will Not Tell You

Recording is frequently the most expensive component of a PAM deployment and the one whose capabilities are most overstated. Naming the limits keeps it credible.

Whether the person was authorised

Why not: the recording shows what was done, not whether it should have been.

Use instead: the grant record and the stated reason, which is why just-in-time requests should carry a purpose.

Whether an action was malicious

Why not: intent is not observable. A destructive command may be an error, a legitimate action, or an attack, and the recording looks identical.

Use instead: the context around it — the request, the ticket, the change record, and a conversation.

What happened outside the brokered path

Why not: the recording covers what went through the broker.

Use instead: target-side authentication logs, compared against broker session records. The difference is your coverage gap and it is the number worth tracking.

What an attacker did after compromising an endpoint

Why not: actions taken through a legitimate administrator's session are recorded as that administrator's.

Use instead: endpoint detection, and the administrative workstation controls that make the compromise less likely.

What happened in cloud

Why not: most cloud administration is API activity with no interactive session.

Use instead: the platform audit log, shipped to a destination the account's administrators cannot alter.

Whether the recording is complete

Why not: a broker that silently stops recording produces sessions everyone believes are covered.

Use instead: explicit alerting on recording failure, and periodic verification that a known session produced a retrievable recording.

What was in the data

Why not: a recording shows a screen or a command stream. Determining what data was accessed usually requires the target system's own logging.

Use instead: data access logging at the application or database layer.

Whether a control is working

Why not: recordings are evidence about individual sessions, not about coverage.

Use instead: coverage metrics — sessions recorded against sessions occurring, systems onboarded against systems in the inventory.

How to decline

Say what the recording does support, which is usually adjacent and useful.

Say what would answer the question and roughly what it costs.

Do not produce a partial answer with a caveat. The caveat is dropped and the answer is quoted, and the recording system's credibility goes with it.

The honest positioning

Recording is evidentiary and deterrent.

It answers what happened in a brokered session, deters when people know it exists, and produces material for an investigation.

It prevents nothing, and a programme that justified its cost on prevention will struggle at the first incident it did not stop.

Measuring the coverage gap

The number that determines what recording can be relied upon for.

Collect target-side authentication events for privileged accounts.

Collect broker session records for the same period.

Compare. Sessions in the first and not the second went around the path.

Group the difference by system and by account, which localises the gap.

Report it as a proportion, which is the honest coverage figure.

Investigate the largest clusters, which usually reveal a workflow the deployment does not support rather than deliberate evasion.

What to say when asked for proof

Recordings are frequently requested as proof of something they cannot establish.

Say what the recording shows: the actions taken in a brokered session at a time by an authenticated identity.

Say what it does not show: intent, authorisation, whether the person at the keyboard was who authenticated, and anything outside the session.

Offer the corroborating sources: the grant record, the change record, endpoint telemetry, the target system's own logs.

Do not overstate it, because the first time a recording is presented as conclusive and turns out not to be, every subsequent one is discounted.