Security posture

The Security posture answers a different question from every other page in this section. Those say what you configured. This one says what is true: how many people have no second factor, how many credentials are reused, whose password turned up in a public breach corpus, which seats you are paying for and nobody is using.

Find it under Security & Compliance → Security posture. Reading it needs the business:audit:read permission — held by Organization Administrator and by Auditor, the role built for someone who audits without being able to change what they are auditing.

The page has two tabs: Overview, with the score, the tiles and the policy and seat counts, and Members, the table of people behind them, with a count badge. They are tabs rather than two pages because a count on Overview switches to Members already narrowed to the people it is about.

An Auditor reads all of this but cannot act on it. Ask to run an analysis, Ask all N to run an analysis and opening a member all need the permission to manage members, which Auditor does not hold — so for them the numbers are there, the ask buttons are not, and rows do not open.

What you can see about a member — and what you cannot#

This is the first question every administrator asks, and the answer is a property of how PulsVault is built rather than a setting you can change.

Visible to an admin	Never visible, to anyone
Counts of weak, reused, old and breached credentials, across every vault the member holds — their personal vault included	Which credential — its name, address, or any field of it
When the member last ran an analysis, and how many credentials it examined	Any decrypted content, from any vault
Whether they have a second factor, how many trusted devices, when they last signed in	The member's master password, or anything about it beyond its age
Whether they meet each of your organization's policies	The contents of a personal vault, or which of its credentials a count includes

The weak / reused / breached flags are computed on the member's own device during a vault analysis and uploaded as plain booleans. Your server has never held the credential and could not produce it if you demanded it. An administrator who needs the detail asks the member.

Members are told this. Each person reads the same row about themselves at Account → Security & compliance (what your organization can see), and the invitation they accepted names these counts before they accept it — a dashboard that reports on people who do not know it exists is a trust problem regardless of what is in it.

The organization score#

A number from 0 to 100, from your organization's total credential counts.

It is deliberately not an average of member scores. An organization of a hundred people where ninety-nine are perfect and one holds a breached production credential would average 99 and be on fire. Penalties are charged per credential, so one breached password costs the same whether you have five members or five hundred. The number is telling you fix that credential, not hire people with better habits.

"No data yet" is not zero. If nobody in your organization has run a vault analysis, there is no score — a zero would say "maximally insecure" when it means "nothing has looked".

Credentials at risk counts credentials, not problems. A password that is weak, reused and breached is one credential at risk. The weak, reused, old and breached counts beside it count problems, so they can add up to more than it — and the Vulnerability assessment report sorts that same total by its worst problem.

Under the score, once there are at least two measured days, a small 30-day line and a change figure (+3, -2 or No change) show which way it is moving, with a See the full trend link to Trend Analysis. A grey What this report can show you note under the tiles repeats the table above in brief — counts, dates and policy status, never which credential — and links to your members' own view of it.

Members analysed#

The tile reads "12/40 analysed" rather than a percentage, because the gap is the thing to act on.

A member who has never run an analysis contributes nothing to your counts and shows as Never analysed in the table. This matters more than it looks: a vault that has been examined and found clean and a vault nobody has opened both report zero problems, and treating the second as the first is the single most misleading thing a security dashboard can do.

The analysis runs on the member's own device, so you cannot start one for them. What you can do is ask — and the Last analysed column tells you who to ask.

Three tiles open the Members tab already narrowed: Members never analysed (the N never analysed … Show them. link under Members analysed), Members with credentials at risk (the show who holds them link under Credentials at risk) and Members with a breached credential (the Rotate these first link under Found in a breach).

Policy compliance#

Each row is one of your policies, and the count is who it currently breaks. The number and the name lead to different places: clicking the count narrows the member table below to exactly those people, and clicking the row's name opens the screen where you change the policy. A count with nowhere to go is a count nobody acts on, and you have already been to the settings page.

Row	Counts	Notes
Members without a second factor	Members bound by Require 2FA for all members who have not enrolled	People still inside their enrolment grace window are not counted — they are not being refused yet
Administrators without a second factor	Admins bound by Require 2FA for administrators	Administrators get no grace window; the requirement binds the moment you switch it on
Members over the trusted-device limit	Members holding more trusted devices than your plan allows
Members with an expired master password	Members whose master password is older than your expiry setting	Reported, never enforced — see below
Members whose password predates the current policy	Members who have not changed their password since you last changed the rules	Not members in breach. A tightened policy cannot rewrite a password that already exists — it binds at their next change, and this is the only way to watch that happen
Members outside your allowed domains	Members whose address your current invitation policy would not admit	They joined before the rule. Removing them is a decision, not a fix
Members over the concurrent-session limit	Members holding more live sessions than your organization allows

When a policy is switched off, its row reads Not required rather than showing 0. An organization that does not require 2FA has no non-compliant members in the same way an unasked question has no wrong answers, and a green zero there would be a clean bill of health nobody earned.

Why password expiry is reported and not enforced#

Your master password is what unwraps your vault key, and that unwrapping happens on your own device. PulsVault holds no key material it could re-wrap with, so it cannot change your master password for you — and it cannot refuse you a session until you do, because changing it requires a session.

So this row tells you who is overdue. Acting on it means asking them.

Seats & access#

Neither credential health nor policy, but the same question — is anything here not as I intended?

• Seats paid for and unoccupied — the same numbers your billing page shows, so the two cannot disagree.
• Members with no sign-in for 90 days — a dormant account still holds live access to everything it was ever granted.
• Invitations pending over 14 days — a seat reserved by nobody. Revoke it or send it again.
• Vaults awaiting a key rotation — somebody lost access to a shared vault and the re-key has not happened. Only a member who holds the key can perform it; the server cannot.
• Organization vaults at their custodian minimum — vaults meeting your custodian floor with nothing spare. Not a violation: they meet the rule. But the next departure takes them below it, and only a member who already holds the key can put a custodian back — so this is a number to read before somebody leaves rather than during their offboarding. Archived vaults are counted, because removing a member is refused over them too; a count that quietly skipped them would let you discover the problem only as a failed removal.
• Machine identities left behind — service accounts whose creator is no longer an active member. They keep authenticating. The member-removal preview warns about these at the moment of removal; this is where they resurface if nobody acted. The number opens DevOps → Machine identities filtered to exactly those accounts, with who created each one.
• Machine keys expiring within 30 days — a key that lapses stops the pipeline using it, and the person who issued it may not be the one who notices. Opens DevOps → Machine identities, where each row shows its next key expiry.
• Open credential alerts — secrets your pipelines depend on that are failing their validation check right now. Opens DevOps → Validation.

The member table#

Sorted worst first, so the row that needs acting on is the first one. Members who have never run an analysis sort below anyone who has — they need a nudge, which is a different action from "go fix four weak passwords".

Search covers your whole organization, not just the page on screen — and so does narrowing.

The columns are the member, their role, their credential health, which of your policies they break, whether they have a second factor, when they were last analysed, when they were last seen, and their score. What is deliberately not here — their trusted-device count, their live sessions, when they last set their password — is in the drawer, because a nine-column table is a table nobody reads.

The Score column is that member's own security score. It can read slightly higher than the number the member sees on their own My security page: the organization report does not run the per-address breach lookup that page does, and an unmeasured component is left at its clean value rather than guessed at.

Who is behind a number#

Every count on this page that is about people narrows the member table to exactly those people. Click 3 beside Members without a second factor and the table below holds those three; the chip above it names the group you are looking at, and clicking the same count again — or the × on the chip — gives you the whole roster back.

Seven counts are not about people and do not narrow the member table: unoccupied seats, stale invitations, vaults awaiting a key rotation, vaults at their custodian minimum, and the three DevOps counts — machine identities left behind, machine keys expiring, and open credential alerts. The DevOps counts take you to the DevOps screen that lists them instead.

You can ask somebody to run an analysis. On a member who has never been analysed, or who is carrying issues, the row offers Ask to run an analysis — it sends them a notification naming you, explaining what you see and what you do not, and linking them straight to the page that runs it.

It is a request, and it cannot be anything else: the analysis runs on that member's device against keys our servers have never held, so nobody — not you, not us — can run it for them. One request per member per day. A second inside that window is accepted and quietly dropped, so you never have to remember who you have already asked. Members with a recent clean analysis are not offered the button at all; there is nothing to ask them for.

You can ask a whole group at once. Narrow the table to never analysed or credentials at risk and the header offers Ask all N to run an analysis. This matters most on a new organization, where nobody has run one yet: an analysis only ever happens when a member opens their own Security Center and starts it, so everyone begins in that state and stays there until they do.

You are told what actually happened — "9 people have been asked. 3 had already been asked in the last day." The cooldown applies per person, so asking the group again tomorrow reaches only whoever was missed. Only those two groups can be asked; an analysis is not the remedy for being over a device limit, so the button is not offered there.

Sending one is recorded in your audit log against the member it was sent to, so "who asked me to do this?" has an answer.

Clicking a member opens them. The same drawer the Members page opens — their role, their teams, what they can reach, their history, and the full version of the security row this table summarises. Opening somebody is not a navigation: the roster you were reading stays behind it, which is the point.

Reading this report is itself recorded in your audit log, including each narrowing — looking up who in your organization has weak credentials is a security-relevant act, not a page view.

Sorting and export#

The Last analysed, Last seen and Score columns sort. Sorting by score puts members nobody has analysed at the bottom in both directions: they have no score, and floating an unknown above a measured problem is the one thing this screen's ordering exists to prevent.

Export CSV downloads the table as it currently stands — your search, your narrowing, your ordering. It carries the same counts and dates the screen does and nothing more; a member who has never been analysed exports blank cells rather than zeroes, for the same reason the table says Never analysed rather than showing a clean row.

When breach monitoring is not included#

If the plan covering your members does not include breach monitoring, the breach column reads Not monitored rather than 0. Every organization tier includes it; you would see this only on a member covered by a plan that does not.

Getting it weekly without opening it#

This page is a live report and nothing about it is pushed to you by default. If you would rather be told than remember to look, turn on the weekly security report under Data & retention → Audit settings: every Monday at 08:00 UTC everyone who can read this page is emailed the score, its movement over the week, the people counts above, and two DevOps counts — credentials failing their validation check and machine keys expiring within 30 days. Nothing at all is sent on a week with nothing outstanding and no movement; a failing credential or an expiring key is enough to send it.

Related#

• Password & auth policies — where the 2FA and expiry rules on this page are set
• Domains & invitation policy — the rule behind the allowed-domains row
• What your organization can see about you — the member's own half of this page, which every member can open
• Audit logs — every read of this report is recorded there, because reading who in your organization has weak credentials is itself worth a record