What we test · Identity
Identity security testing
In one paragraph
Identity security testing checks whether an attacker can become someone they are not: sign in without the right factors, keep a session they should have lost, or turn one ordinary account into an administrator. It covers single sign-on and identity providers, multi-factor authentication, password and session policy, OAuth app consent, privileged accounts and directory services such as Active Directory and Microsoft Entra ID. Because most modern breaches involve a valid account somewhere, identity is often the shortest path to real impact.
What the test covers
Single sign-on and the identity provider
How your identity provider is configured, which apps rely on it, and whether any app can be reached without going through it.
MFA coverage and strength
Accounts, apps and legacy protocols that skip multi-factor authentication, and whether factors in use resist phishing or can be relayed or fatigued.
Password policy
Whether rules favor length and block known-compromised passwords, and whether lockout and throttling stop guessing without enabling easy lockout of staff.
Session handling
Session lifetimes, revocation on password change or offboarding, and whether stolen session tokens can be replayed from another device.
Privileged accounts
Who holds admin rights, whether those accounts are separate from daily ones, and how many standing global admins exist.
Directory services
Active Directory and Entra ID configuration: delegation, group nesting, service accounts and hybrid sync paths that let ordinary users climb toward domain or tenant admin.
OAuth and app consent
Third-party apps granted broad access to mail or files, user consent settings, and OAuth redirect and token handling in your own apps.
Recovery and help desk flows
Account recovery, MFA reset and onboarding steps, which attackers target because they bypass the strongest controls by design.
Why test identity separately from apps and networks?
In a company that runs on SaaS, the identity provider is effectively the perimeter. Email, source code, customer support, payroll and cloud consoles all sit behind one sign-in. A weakness there is not a bug in one app; it is a key to many of them. Web and network tests touch identity at the edges, but they rarely examine the whole system: the policies, exceptions, legacy protocols, admin roles and recovery paths that decide who can become whom.
Identity weaknesses also tend to be policy exceptions rather than code defects. A conditional access rule that excludes a service account, a break-glass admin without MFA, a legacy protocol left on for one printer. Each made sense to someone once. A tester's job is to find which exceptions an attacker could use.
What identity gaps does testing usually look for?
| Weakness | Why it matters | Typical fix |
|---|---|---|
| MFA not enforced on every app or protocol | Attackers sign in through the one path without it | Enforce at the identity provider; disable legacy authentication |
| Phishable MFA on admin accounts | Codes and push prompts can be relayed or fatigued | Phishing-resistant factors such as FIDO2 security keys or passkeys for privileged roles |
| Sessions not revoked on offboarding | Former staff or stolen tokens keep access | Revoke sessions and tokens centrally on account changes |
| Too many standing admins | One compromise gives full control | Just-in-time elevation and separate admin accounts |
| Over-permissive OAuth consent | A malicious app can read mail or files | Restrict user consent; review granted apps |
| Directory delegation paths | Ordinary users can chain group rights to admin | Clean up delegation and tier admin access |
On passwords, current guidance has moved away from forced complexity. NIST SP 800-63B-4, finalized in July 2025, favors longer passwords, screening against known-compromised lists, and not forcing arbitrary composition rules or periodic changes. Testing checks whether your policy and enforcement match that intent. For MFA, CISA recommends phishing-resistant methods, especially for accounts with elevated privileges.
How is identity testing scoped and run safely?
Identity testing mixes configuration review with hands-on attack. A read-only admin view of the identity provider and directory lets the tester map policies and privilege paths quickly. Hands-on work then proves which paths are real, starting from an ordinary test account rather than from admin.
- Password guessing is limited and coordinated so real staff are never locked out.
- Help desk and recovery testing is only done with explicit agreement, because it can involve social engineering of staff.
- No real user's credentials or data are used beyond what the scope allows.
- Changes made to prove a path (such as adding a test account to a group) are logged and reversed.
How are identity findings proven and fixed?
An identity finding is proven when the operator shows the path working: the test account reached an app without MFA, or climbed from user to an admin role, with each step recorded. In Brexa's Resolve stage the fix goes to whoever owns the identity platform with specific settings to change. Because identity fixes can lock people out if rushed, they are often staged, starting with privileged accounts. Verify re-runs the exact path and closes the finding only when it fails.
Two ways to engage
Test this surface once with a one-time vulnerability assessment, or keep it under continuous testing with autonomous agents. Either way every finding is reproduced by a person before it reaches you, and closes only after a retest shows the original attack fails.
Frequently asked questions
Does identity testing include phishing our employees?
Only if you ask for it and it is written into the rules of engagement. Most identity testing focuses on configuration and policy, which can be tested without targeting staff.
We use Google Workspace or Okta rather than Microsoft. Does this still apply?
Yes. The questions are the same for any identity provider: where MFA is missing or weak, how sessions are managed, who holds admin roles, and which apps have broad access.
Is having MFA enabled enough?
It is a large improvement but not the end. Testing often finds accounts or protocols excluded from MFA, and factors that can be phished or relayed on the accounts that matter most.
References
Guides for this surface
Other surfaces we test
Book a identity assessment.
Book a short scoping call. Nothing is tested until scope and rules of engagement are signed, and every finding comes with proof.