Identity controls often determine whether a technical weakness becomes a business incident. Authentication, authorization, privileged access, and provider trust all sit on the path to a critical function. If those controls are not included in testing, the organisation may validate a vulnerability without validating the actual operational risk it creates.
Why This Matters for Security Teams
DORA penetration testing is not just about finding exploitable flaws. It is about proving that critical services keep working when attackers target the identity layer, where authentication, authorization, session handling, and privileged access decisions are enforced. A system can pass a vulnerability scan and still fail in practice if an attacker can reuse a token, escalate privileges, abuse service accounts, or move through a third-party trust boundary. That is why identity controls belong in scope when teams test resilience under DORA --- Digital Operational Resilience Act.
The operational concern is simple: many business-impacting incidents do not begin with a software bug alone. They begin when a weakness meets weak identity governance, overly broad access, or insufficient segmentation between users, administrators, and connected providers. DORA’s testing expectations are aimed at realistic disruption, not checkbox validation, so identity paths must be treated as part of the attack surface. If a test excludes privilege escalation, credential abuse, or trust assumptions in access delegation, it can produce a misleadingly clean result.
In practice, many security teams discover the real failure only after an attacker has already used valid access to bypass the very control the test was supposed to validate.
How It Works in Practice
Identity-aware DORA testing starts with mapping the paths that matter to a critical business service. That includes human users, administrators, federated identities, service accounts, API credentials, break-glass access, and any outsourced or cloud provider accounts that can reach the target function. The test should not stop at perimeter exploitation. It should ask whether an initial foothold can become meaningful access through weak authorization, missing reauthentication, stale secrets, or excessive trust in a supplier-controlled identity plane.
Good programs translate that risk into test cases. For example, testers may validate whether a low-privilege user can access administrative workflows, whether an expired token is still accepted, whether privileged sessions are monitored, or whether a shared account masks accountability. They may also assess whether identity events trigger detection and response, because resilience is not only about prevention. Under EU Digital Operational Resilience Act (DORA), the point is to exercise realistic failure paths against the services that matter most.
Practitioners usually structure this work around a few questions:
- Can an attacker move from one authenticated role to another without proper authorization?
- Can privileged access be gained, retained, or reused after intended revocation?
- Do secrets, tokens, and service credentials create a hidden path into critical systems?
- Do third-party integrations inherit trust that has not been tested under failure conditions?
- Would logging, alerting, and response actually reveal identity misuse quickly enough to matter?
The strongest programs combine adversary emulation with control validation, then tie results back to remediation in IAM, PAM, and supplier governance. That is especially important where access is federated across cloud services, outsourced operations, or shared platforms, because the weakest identity boundary often becomes the shortest path to operational disruption. These controls tend to break down when environments rely on sprawling service accounts and inherited cloud trust because ownership, revocation, and monitoring become fragmented across teams and providers.
Common Variations and Edge Cases
Tighter identity testing often increases programme complexity, requiring organisations to balance realistic attack simulation against operational safety and regulatory scope. Not every system can be tested in the same way, and current guidance suggests the approach should match the criticality of the service, the architecture, and the blast radius of failure.
There is no universal standard for how deep identity testing must go in every case. For highly regulated or interconnected environments, teams may need to include privileged access abuse, federated login paths, and supplier identities in the test design. In less exposed environments, the focus may be narrower, but excluding identity entirely is rarely defensible if the service depends on access control to function safely. The key judgment is whether the test measures how the control actually behaves under attack, not just whether the control exists on paper.
Identity controls also become more complicated when emergency access, automated workflows, or cross-border outsourcing are involved. Break-glass accounts may be necessary, but they should still be tested for approval, monitoring, and revocation. Automated service identities may be legitimate, but they should not be exempt from lifecycle management or audit. Where a provider controls part of the authentication chain, the organisation must understand whether the resilience obligation sits only with the internal platform team or also with the vendor contract and assurance model. For background on the regulatory context, the DORA guidance from EIOPA remains a useful reference point.
The edge case to watch is a service that appears technically robust but depends on one privileged identity or one supplier trust path. In those environments, the test often fails to reflect true operational exposure unless identity misuse is included from the start.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, NIST CSF 2.0 and NIST SP 800-63 set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control are central to attack-path testing in regulated services. |
| MITRE ATT&CK | T1078 | Valid Accounts is a common path from initial access to business impact in DORA testing. |
| DORA | DORA requires realistic testing of critical functions, including identity-dependent access paths. | |
| NIST SP 800-63 | AAL | Authentication assurance levels matter when testing whether login controls resist misuse. |
Test whether identity-based access paths are limited, monitored, and resilient under realistic attack conditions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
