When a rule inside an elevation policy was added, removed or modified, the resulting event recorded only the number of rules the policy ended up with. Two different changes could produce identical-looking events, so the log told you a policy had been edited but not what the edit was.

Events now describe the change itself:

Changes that loosen or tighten an elevation rule are now traceable after the fact, and a deleted rule leaves a record of what it contained rather than having to be reconstructed from memory.

Events recorded before this release keep their original level of detail.

Creating a JIT account from the browser extension created the account but didn't select it afterwards — and didn't reliably place it at the top of the list either. Whichever account was selected beforehand stayed selected, so using the copy function straight after creating a JIT account could copy credentials for a different account, belonging to a different customer. Easy to miss where customers have similar names.

Creating a JIT account from the browser extension now selects the new account, so the copy function acts on the one you just created.

Search and filtering are unchanged: if you have an active search term or filter the new account doesn't match, it still won't appear in the current results.

The browser extension updates automatically; check for extension updates in your browser if you want it immediately.

Events recording the deletion of an account previously identified the account by name. Account names aren't guaranteed to be unique, so an integration reconciling a deletion against its own records could match the wrong account where two shared a name — or fail to match at all.

Every type of delete account event now includes the , so you can key on a unique, stable identifier and resolve exactly which account was removed.

Existing fields on these events are unchanged — the account ID is additional, so current integrations keep working without modification.

Full event schema: https://us.getquickpass.com/api/docs

The Technician Users list now has a column, between Login Role and Status, showing which Technician Groups each technician belongs to. Previously the only way to find this out was to open each Technician Group in turn and look at its assigned users.

Where a technician belongs to more groups than the column displays, a indicator shows how many more there are, and hovering over the column reveals the full list. The column can be resized like the others.

Technicians with the Super or Primary login role can't be assigned to a Technician Group, so their rows show the usual empty placeholder.

Handy when reviewing access, since Technician Group membership determines which customers a technician can work with and which alerts they receive.

When approving a one-time elevation request, the note on the screen said the end user could enter elevated mode once within — twice the window that actually applies.

The message now correctly states , matching the period in which an approved one-time elevation can be used.

If you'd previously told an end user they had 48 hours based on this message, the real window was shorter — an elevation left unused beyond 24 hours would have needed a new request. This was a wording correction only; the elevation window itself hasn't changed.

Signing in to CyberQP could fail intermittently — a significant proportion of attempts returned a "Forbidden" error instead of completing. Retrying usually worked, so most people just tried again, sometimes several times. It affected every region and any client that signs in through CyberQP, including the Tech Vault browser extension.

Signing in involves two steps that need to be handled together, and the second step could be picked up by a different server from the one that started the process — a server with no record of the sign-in already underway. The sign-in then couldn't be completed, even though the credentials and permissions involved were perfectly valid.

The information needed to complete a sign-in is now shared across all servers, so the second step succeeds whichever server handles it. Sign-in completes reliably on the first attempt.

If your technicians ran into this, it was a problem with their account, credentials or permissions, and it didn't mean access had been revoked. Using seemed to help at the time but had no actual bearing on it — the next attempt simply had a chance of working. That step is no longer needed.

Moving a customer from one automatic import policy to another used to mean editing the policies themselves — removing the customer from one, then finding and editing another to add them. A new button on the customer's screen now does it in one step.

The button reads when a policy is already assigned, or when none is. Selecting it opens a dialog listing only the policies that apply to the section you're in — End User Import Options, End User Import Source, Administrator Import Options, or Administrator Import Source — sorted alphabetically, with the current policy pre-selected. Hovering over a policy shows which options it has enabled, so you can check what it does before switching a customer onto it.

Confirming updates everything at once: the customer is removed from the old policy's customer list, added to the new one, and the policy name and link on the screen update.

If a switch would change the import source, you're warned before committing, with a pointer to the password sync option if you need both Active Directory and Microsoft 365. You can't switch to a Microsoft 365 policy while password sync is enabled, or enable password sync while on a Microsoft 365 policy. The buttons are unavailable while an import is running, so a change can't land mid-import.

If the import source was disabled, assigning or switching a policy runs the import immediately and re-enables it.

Each one creates an event showing the policies involved, the customer, the account type and the technician who made the change — filterable and exportable like any other event.

The buttons appear only for roles with permission to create and manage policies.

Please reach out to Support support@cyberqp.ai to enable this feature during the phased roll out stage.

On Password Vault tenants, every row in the Password Rotations report showed a QP Status of , whatever the underlying rotation status actually was. Because the column returned the same value for every entry, it said nothing about the state of your rotations and couldn't be used to spot entries that needed attention.

The QP Status column now reflects the actual status of each password rotation, so the report shows the real state of rotations across the tenant. If you'd previously discounted this report because every row looked unmatched, it's worth another look.

This affected how the status was reported only — rotations themselves ran as configured.

Extending the timer on an active JIT account now does what you'd expect across every account source.

For Active Directory and Entra ID / Microsoft 365 accounts, the countdown to automatic expiry previously carried on unchanged, so the account was disabled at its original time regardless of the extension. Extending now adds the selected period to the time remaining, and the dashboard shows the new expiry — a one-hour JIT account extended by an hour after 35 minutes will show 1 hour 25 minutes remaining.

Extending also regenerated the password on Active Directory and Local accounts, so a technician already signed in with that credential found it no longer worked — the opposite of what extending a session is for. The existing password is now left in place across all sources.

This applies consistently to Active Directory, Local and Entra ID / Microsoft 365 sources, to both standard and burner JIT accounts, and whether you extend from the dashboard, the browser extension or the QTech mobile app. Events recorded for an extension show the correct updated expiry time.

Password Edited audit events used to show only each field had changed — a YES or NO against it. They now record what actually changed.

for Display Name, Username, Account Type, Computer Name, URL, Notes and Password Access. Previously a change to Password Access recorded only what it had been changed , so there was no way to tell from the audit trail what access had been in force beforehand. The YES/NO indicators remain, with the detail beneath them.

— the event states whether a passcode was created, changed or deleted, so a second factor being removed from an account is visible in the audit trail rather than looking like any other edit.

Password and passcode values are not written to events; for these fields the event says only that a change occurred — the password was changed, the secret key was removed — never the value before or after.

Edits to an account linked to a source open with , and entries in Other Passwords with , with the Source column showing the account name.

Events recorded before this release keep their original level of detail.