Notifications
Clear all
Topic starter
17/08/2026 4:38 pm
TL;DR: DORA compliance in practice is less about policy wording and more about proving who accessed what, when, how, and why, according to Teleport’s webinar summary. The practical gap is that identity governance, auditability, and third-party access controls must be operationalised, not documented, if financial institutions want resilience under real scrutiny.
NHIMG editorial — based on content published by Teleport: Exploring DORA Compliance in Practice: Key Takeaways from Our Recent Webinar
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should financial institutions implement just-in-time access for regulated infrastructure?
A: Start by restricting elevation to a specific task, resource, and time window.
Q: Why does standing privilege create problems for DORA compliance?
A: Standing privilege leaves no clear justification boundary between access granted and access actually needed.
Q: How can teams tell whether their access logs are audit-ready?
A: Audit-ready logs tie identity, privilege elevation, and session activity together in one searchable record.
Practitioner guidance
- Map regulatory asks to evidence-producing controls Translate DORA obligations into concrete signals such as access history, privilege elevation, session replay, and exportable logs.
- Eliminate standing admin access where tasks are time-bound Identify infrastructure roles that remain active beyond a discrete maintenance or support window.
- Unify session logging across infrastructure and providers Correlate authentication, privileged action, and audit events into one traceable record for internal teams and third-party operators.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- A live webinar walkthrough of how RBAC, JIT access, and session recording map to DORA requirements.
- Examples of how short-lived certificates and passwordless access reduce standing privilege in regulated infrastructure.
- A practical explanation of how audit logs and session timelines support incident reporting and compliance evidence.
- The webinar framing used to translate Articles and RTS points into operational controls.
👉 Read Teleport's webinar summary on DORA compliance in practice →
DORA compliance and access control: what IAM teams need now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:44 pm
DORA makes access governance an operational resilience control, not a documentation exercise. The article’s core message is that regulated institutions must prove who accessed what, when, how, and why. That shifts identity governance from policy intent to audit-ready evidence. Practitioners should treat access control design as part of resilience architecture, not an after-the-fact compliance layer.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
A question worth separating out:
Q: Who is accountable when third-party administrators access regulated systems?
A: The regulated organisation remains accountable for proving that third-party access was controlled, scoped, and revoked on time. The provider may operate the system, but the customer still needs evidence of approval, session visibility, and offboarding. In DORA terms, accountability cannot be outsourced with the access itself.
👉 Read our full editorial: DORA compliance in practice exposes identity control gaps
