Credentials
The Credentials page (labeled "Auth Endpoints" in the page header) is your inventory of every place employees authenticate: corporate identity providers, sanctioned SaaS, and the login pages nobody knew were in use. For each authentication endpoint, Surface Security shows who signs in there, whether multi-factor authentication is in place, which identity provider fronts it, and which applications rely on it — all derived from real sign-in activity observed by the browser extension.
One principle governs everything on this page: passwords never leave the endpoint. The extension observes that a login happened and derives privacy-preserving signals from it locally. The actual password is never transmitted to Surface Security, never stored, and never recoverable from anything that is transmitted.
[SCREENSHOT PLACEHOLDER: The Credentials page showing the Total Auth Endpoints, MFA Adoption Rate, and IDP Distribution stat cards above the endpoint table]
How it works
When an employee signs in to any site, the extension on their browser detects the authentication flow and records metadata about it: the origin, the login path, whether an MFA challenge occurred and of what kind, and whether a single sign-on redirect was involved. From this activity the platform builds and continuously updates the authentication endpoint inventory, including per-user MFA status at each endpoint.
Credential hygiene without the credential
Hygiene signals are computed on the endpoint itself, using techniques that make the password unrecoverable:
- Fingerprinting, not capture. The extension derives an HMAC-SHA256 fingerprint of the credential using a device-specific secret held in the operating system keychain. The fingerprint cannot be reversed into the password, and only the fingerprint is used for comparisons.
- Password reuse detection. By comparing fingerprints locally, the extension recognizes when the same password is used at more than one site — for example a corporate password reused on a personal service. Reuse is tracked per credential (which endpoints it was used at, how many times) and raises a Credential Reuse alert, including the source and target origins.
- Breached password detection (Have I Been Pwned). Passwords are checked against the HIBP breach corpus using the k-anonymity model: the extension computes a hash of the password locally, sends only the first five characters of that hash to the HIBP API, receives the list of breached-hash suffixes matching that prefix, and completes the match locally on the device. Responses are also padded to defeat traffic analysis. HIBP never sees the password or even its full hash. A match raises a Pwned Password alert, and the affected credential is marked with a breach-count bucket rather than an exact figure.
Endpoint-level results — pwned status, reuse status and counts, last breach-check time — appear on each employee's profile under Users, and drive the credential-risk figures on the main dashboard. The Credentials page itself focuses on the endpoint view: where authentication happens and how well protected it is.
MFA visibility
MFA detection is per user, per endpoint. As sign-in flows complete, each endpoint accumulates an MFA adoption rate (the share of its users seen completing MFA) and a status:
| Status | Meaning |
|---|---|
| Enabled | All observed users complete MFA at this endpoint |
| Partial | Some users complete MFA; the percentage of users is shown |
| Disabled | Sign-ins observed with no MFA |
| Pending | Not enough completed sign-in flows yet to judge |
Detected MFA methods are listed per endpoint and per user, using labels such as Passkey / WebAuthn, Authenticator App (TOTP), Push Notification, SMS, and Email.
Using the page
Open Attack Surface > Credentials in the sidebar. Three cards summarize posture:
- Total Auth Endpoints — every authentication endpoint discovered
- MFA Adoption Rate — the aggregate adoption across endpoints (shows N/A until enough flows have been observed)
- IDP Distribution — how many endpoints sit behind each identity provider
The table lists each endpoint with its Origin (and login path), IDP Type (Okta, Microsoft Entra ID, Google Workspace, Ping Identity, Auth0, or Unknown), MFA status, Logins, Users, and First Seen / Last Seen dates. Filter by identity provider with the All Identity Providers dropdown.
Two display details worth knowing:
- In the Logins column, a Detected badge means authentication activity (such as an MFA challenge) was confirmed but no completed password login has been counted — typical for passwordless or MFA-first sign-in flows.
- If the list is empty, endpoints appear once employees sign in to sites with the extension installed; the built-in "How auth endpoints work" tour walks through the lifecycle.
[SCREENSHOT PLACEHOLDER: The endpoint table filtered to one identity provider, showing MFA status chips including a Partial entry with its percent-of-users figure]
The endpoint detail page
Click any row to open Auth Endpoint Details for that origin.
- Overview — identity provider, total logins, unique users, and the MFA adoption rate for this endpoint.
- MFA Configuration — the effective MFA status and the observed MFA types. If the endpoint enforces MFA but detection has not picked it up (for example, MFA handled out-of-band), use Mark as MFA Enabled to set a manual override; the status then shows a Manual Override chip and all logins are counted as MFA-enabled. Remove MFA Override returns to automatic detection.
- SSO Configuration — whether single sign-on was detected, the provider, and the login path.
- Technology Stack — technologies fingerprinted at this endpoint with confidence scores.
- Timeline — first and last observed activity.
- Users — every employee who has authenticated here, with department, per-user MFA status (Enabled, Disabled, or Pending while their flow is incomplete), MFA type, the IDP that handled their sign-in, login count, and first/last seen. Sort by any column — sorting by MFA status is the quickest way to enumerate exactly who is exposed at a partially covered endpoint.
- Relying Parties — for identity-provider endpoints, the applications that delegate authentication to it. This shows the blast radius of the IDP: every application a compromise of this endpoint would reach.
If an endpoint was confirmed malicious during alert triage, the detail page shows a prominent banner: the endpoint is hidden from listings and will not be re-created from new credential events, with a link to the alert that triggered the flag.
[SCREENSHOT PLACEHOLDER: Auth Endpoint Details page showing the Overview cards, the MFA Configuration card with the Mark as MFA Enabled button, and the Users table]
What administrators do with this
- Close MFA gaps. Work down the endpoint list from Disabled and Partial status. On each detail page, the Users table names the individuals still signing in without MFA.
- Correct detection. Apply the Mark as MFA Enabled override for endpoints whose MFA is real but invisible to browser-side detection.
- Act on hygiene alerts. Credential Reuse and Pwned Password alerts arrive in the alerts queue (see Alerts) with the affected user and origins; per-user credential detail lives on the employee's profile.
- Map identity dependencies. Use Relying Parties on IDP endpoints to understand which applications inherit risk from each identity provider, and cross-check delegated application access on the OAuth Consent Grants page.
- Spot unsanctioned authentication. A new endpoint with real user counts and an Unknown IDP is often shadow IT holding corporate credentials — the same sweep described in Attack Surface Discovery. A New Auth Endpoint alert can notify you when one first appears.
Worked example: auditing an MFA rollout
A security team mandates MFA on all business applications by end of quarter. On the Credentials page, the MFA Adoption Rate card reads 71%. Filtering and sorting the table surfaces a CRM endpoint at Partial — 64% of users. The administrator opens its detail page and sorts the Users table by MFA status: 19 users show Disabled, most from one regional office, all authenticating with password only while the rest of the company uses Authenticator App (TOTP).
The team targets enrollment outreach at those 19 users. Two weeks later the endpoint reads Enabled and the org-wide adoption card has moved to 89% — measured from actual sign-in behavior rather than self-reported policy compliance.
FAQ
Does Surface Security ever see a password? No. Detection, fingerprinting, and breach checking all run on the endpoint. Transmitted data is limited to one-way HMAC-SHA256 fingerprints and authentication metadata; the HIBP check sends only a five-character hash prefix to the HIBP service, never to Surface Security and never the password.
Why does an endpoint show Pending? Not enough completed sign-in flows have been observed to determine MFA status. It resolves as users authenticate.
Why does an endpoint show zero logins but a Detected badge? The endpoint uses passwordless or MFA-first authentication, so there is confirmed auth activity without a counted password login.
A site my team uses isn't listed. Endpoints are discovered from real sign-ins through browsers running the extension. Confirm the extension is deployed to those users and that they have signed in since deployment.
Where do I see a specific user's reused or breached passwords? On the user's profile under Users, which summarizes their credentials with pwned and reuse status, and in the corresponding alerts.