An exposed account matters partly because of what it can access. A mailbox used for ordinary correspondence and an administrator identity with permission to change production settings can appear in similar-looking records. Their business context is different, even when the evidence format is identical.
Useful prioritization makes that context explicit. Start with accounts and services your organization knows, connect them to the observed evidence, and explain why a reviewer should look more closely. A priority label should never silently become a claim of confirmed compromise.
Build a short list from current account information
Ask service owners which work identities hold administrative or otherwise sensitive permissions. Record the exact work email used for each identity and confirm that it still has the relevant access. A person's ordinary mailbox may differ from their administrative account.
For example, the fictional addresses [email protected] and [email protected] should not be treated as interchangeable. A rule for one address does not establish the privileges of the other. Shared mailboxes and service accounts also need deliberate identification rather than assumptions based on a name.
Keep this list grounded in your current directory and service configuration. Exposure data cannot discover every current permission assignment for you.
Verify the domains that contain your targets
In Vuxep, priority targets must belong to a verified organization domain. That requirement applies to both work email addresses and service hostnames. Verify the relevant domain before trying to create a rule for it.
An organization administrator manages these rules under Organization → Priorities. Platform administrators can manage them for an organization as well. Viewers can inspect the configured priorities and resulting evidence but cannot change the rules.
If scope is still incomplete, follow the guide to checking company credential exposure first. A rule cannot substitute for verifying the domain that authorizes the review.
Choose the rule that expresses the reason
Two useful starting points are an exact privileged work email and a critical service hostname.
| Rule | Example target | What it explains |
|---|---|---|
| Privileged account | [email protected] | This exact account has sensitive access according to your organization |
| Critical service | admin.example.com | This hostname and its subdomains support an important service |
Choose the narrowest service hostname that represents the intended scope. Marking a company's root domain as critical also includes its subdomains; that may be broader than the team intended. Use a clear label to explain the business purpose without placing sensitive information in the label itself.
These rules express your organization's knowledge. They do not independently verify the privileges of an account or the business importance of a service.
Open the employee exposure profile
When a work email appears in results or the dashboard, its exposure profile brings related services, observed hosts, indexed evidence, and priority reasons together. The profile response excludes passwords, hashes, and original URL paths.
Compare the observed services with the account's expected use. An administrative identity associated with an unfamiliar external service may deserve a closer look. First establish whether the association is recognizable; the record alone cannot explain why it exists.
Larger profiles analyze a limited sample of up to 5,000 indexed records and indicate that limitation. Treat the profile as a view of available evidence, not a complete inventory of every account the person has ever used.
Read the reasons separately
A privileged-account label comes from a configured rule. A password-reuse signal describes matching account-and-password observations across service domains. A newly indexed label describes when evidence entered the index. These reasons answer different questions.
Reuse counts can be lower bounds because analysis is bounded. Search priority sorting also applies to the current results page, so the first item is not necessarily the highest-priority record across every page of a large search. Read how password-reuse signals work before presenting a count as exhaustive.
Several reasons can justify closer attention without proving that a password still works or that anyone accessed the account.
Connect the evidence to current protections
Use authorized internal systems to check present privileges, authentication settings, and sign-in evidence. Do not test exposed credentials against live accounts as part of a routine review. Current access controls and historical exposure observations are separate sources of information.
NIST's authentication guidance distinguishes passwords from phishing-resistant authentication. A record containing a password does not tell you which protections were active when the observation occurred or which protections apply now.
Share a short explanation of the account category, affected services, indexing context, and remaining uncertainty. Use a redacted exposure report for a management audience, and configure targeted alerts when future matches should reach a specific team.
Talk to Vuxep about prioritizing evidence within your verified domains.