3366 Members
Join Permit's SlackDORA and NIST do not prescribe buying a specific vendor. They expect scoped, least-privilege access control and attributable audit evidence, including for non-human identities. Application fine-grained authorization with decision logs is how product teams produce that evidence at the application layer, where tenant, resource, action, and delegation context actually exist.
DORA — Regulation (EU) 2022/2554 — is not an authorization-product checklist. It does not say "implement fine-grained authorization," and it definitely does not say "buy Permit." What it pushes financial entities and their ICT providers toward is a defensible operating model for ICT risk: access should be limited, traceable, reviewed, and revocable.
For application teams, the important point is that "access" is not just login. An identity provider can tell you that Alice authenticated with MFA, issue tokens, and manage groups. That is necessary. But inside a multi-tenant SaaS application, the actual risk is usually more specific:
That is application authorization — where resource, tenant, action, ownership, and business context meet.
DORA Article 9-style ICT security expectations are commonly read around themes like protecting ICT systems, limiting access, and reducing the impact of unauthorized activity. The RTS on ICT risk management — Commission Delegated Regulation (EU) 2024/1774 — goes deeper into identity management and access control themes in Articles 20 and 21. Carefully stated, those themes include unique identification of persons and systems; need-to-know and least privilege; grant/change/review/revoke lifecycle handling; stricter privileged access; logging of relevant access events; and controls that support accountability and investigation.
None of that mandates a particular architecture. But it does create a practical question: can you prove, for a specific application action, that access was scoped correctly at the time of the decision?
If the answer is "we can show the user was in an IdP group," that may not be enough. IdP groups rarely encode tenant membership, ownership, approval thresholds, data classification, resource relationships, temporary elevation, or delegation. Many companies fail here not because they lack IAM, but because authorization logic is scattered across services, route guards, SQL filters, frontend conditionals, and undocumented if statements. When someone asks "why was this allowed?", the answer becomes archaeology.
Separate three layers:
IdP/IAM owns a major part of layer one. Application fine-grained authorization owns layer two. Decision logs and audit trails produce layer three.
NIST SP 800-53 Rev. 5 is also not a product prescription. It is an outcome-oriented control catalogue. Organizations select and tailor controls based on risk, obligations, and customer requirements.
Two families matter most here: AC — Access Control and AU — Audit and Accountability.
AC covers themes like account management, enforcing authorized access, least privilege, separation of duties, and controlling access to systems and resources. In application terms: are you enforcing the right access boundary, consistently, and can you manage that boundary over time?
AU covers audit events, record content, review and analysis, protection of audit information, and supporting investigation. In application terms: when something happened, can you reconstruct who did it, what happened, when, and why the system allowed or denied it?
NIST does not say "use FGA" or "use Permit." Application authorization decisions still map naturally to these outcomes. A well-designed authorization system can answer which principal attempted the action; whether it was a human, service account, workload, or agent; which tenant, resource, and action were involved; which policy, attributes, or relationships were evaluated; and whether the result was allow or deny — and why.
That is the bridge between AC and AU: enforcement plus evidence. If decisions are inconsistent, audit evidence is weak. If decisions cannot be explained, access control is hard to defend.
In SaaS and fintech, authorization is rarely simple RBAC. You may need RBAC for product roles, ABAC for attributes like geography or transaction amount, ReBAC for ownership and delegation, policy-as-code for reviewable changes, and administrative controls over who can change the model itself. Match the enforcement layer to the product's real risk model — without over-engineering day one.
Non-human identities are not new. Service accounts, API keys, CI/CD workloads, and integration tokens have existed for years. What is new is how quickly AI agents are being connected to production systems and business workflows.
An agent that can read data is an identity. An agent that can call tools is an identity. An agent that can modify state is a high-risk identity. An agent acting on behalf of a user is a delegated identity with accountability requirements.
Ask the harder questions: what can the agent do as itself versus on behalf of a user? Can it inherit all user permissions, or only a scoped subset? Can it take destructive actions or cross tenants? Can a human approve, constrain, or revoke its authority? Can you explain the decision later?
NIST NCCoE's work around Software and AI Agent Identity and Authorization is directionally important. It is an emerging project focus area, not a finalized mandatory control set. The framing points where the industry is going: agent identity, authorization, delegation, accountability, logging, and transparency.
"The AI did it" is not an acceptable audit answer. Logs need to attribute who initiated or delegated the action; what agent or workload acted; on whose behalf; which resource and action; which policy was evaluated; allow or deny; and why. A customer-success agent summarizing an account may be low risk. The same agent changing billing terms or exporting transactions is not. Do not control that with agent_enabled=true. Treat the agent as a principal with scoped entitlements. Keep delegation explicit. Preserve both the non-human actor and the human context in the log.
This mapping is not a legal compliance matrix. It is a practical engineering translation of DORA-style and NIST AC/AU-style expectations into application authorization capabilities and evidence.
| Expectation | AuthZ capability | Evidence artifact |
|---|---|---|
| Least privilege / need-to-know | Policy models that combine RBAC, ABAC, and ReBAC so access is scoped by role, attributes, relationships, tenant, resource, and action | Policy definitions, policy-as-code review history, allow/deny decision logs showing evaluated scope |
| Unique identification of humans and systems, including agents | Principals modeled explicitly: users, service accounts, workloads, API clients, and agents; PEPs pass principal identity and context into each check | Decision logs containing principal ID/type, agent ID where relevant, tenant, resource, action, timestamp |
| Privileged / elevated actions | Dedicated policies for admin actions, break-glass flows, approval conditions, time-bound access, and AuthZ-for-AuthZ over who can change policy | Logs of privileged authorization checks, policy change audit trail, approvals or elevation metadata |
| Access grant / review / revoke lifecycle visibility | Centralized authorization model and policy-as-code so grants, role assignments, relationship changes, and revocations are visible and reviewable | Policy repository history, relationship/assignment records, access review exports, revocation evidence |
| Access event logging / attributable decisions | PEP checks evaluated by a PDP; automatic decision logs with allow/deny result, input context, and human-readable reason | Authorization decision logs and audit logs, filterable by user, resource, tenant, action, result, or time |
| Investigation of unauthorized or unexpected access | Centralized policy evaluation, hybrid PDP decision records, policy versioning, and searchable audit trails | Incident investigation timeline showing decision, policy, data, actor, resource, and reason |
| Protection of the authorization plane itself | AuthZ-for-AuthZ: explicit controls over who can create policies, change roles, modify tenants, or administer permissions | Admin activity logs, policy change records, separation-of-duties evidence |
Security teams need this level of evidence — not "the user had a token," and not "the frontend hid the button." A defensible answer shows that a backend enforcement point made a scoped decision and that the decision can be reconstructed.
Most SaaS authorization starts with an isAdmin flag, then tenant membership, custom roles, support access, service accounts, delegated administration, access-review evidence requests, and eventually AI tool permissions. The original model becomes a pile of conditional logic.
Scattered if checks fail audits because they are hard to enumerate, hard to reason about across services, and hard to evidence even when the decision was correct.
Application FGA creates a clearer architecture:
Permit's architecture separates those concerns. The control plane manages policy and configuration; the data plane performs authorization checks close to the application. See the docs on control plane and data plane and how Permit works.
With a hybrid PDP model, decisions can be made locally near your application — better for latency, resilience, and data minimization. OPAL — Open Policy Administration Layer — keeps policy and authorization data updated in near real time. When a user is removed from a tenant, a relationship changes, or a role is revoked, the local decision layer should learn quickly. Stale authorization data is a security bug.
Permit supports RBAC, ABAC, and ReBAC so teams can start simple and evolve. The foundation is in policy basics. The evidence side matters just as much: decision records for customer questions, logs for privileged-access monitoring, and searchable history for post-revocation investigation. See audit log types and filtering.
This is why I keep pushing teams not to rebuild permissions from scratch in every product. More on that in Stop Rebuilding Permissions. If your security team has asked "why was this allowed?", see Why Was This Allowed? Authorization Logs. The same logic applies to explainable denies in SOC 2-style evidence workflows: Explainable Deny.
Across DORA, NIST, SOC 2, and enterprise reviews, controls are only as strong as the evidence behind them. A frontend check can be bypassed. A JWT claim may be too coarse or stale. An IdP group usually lacks resource context. A ticket saying "access was approved" is not enough if runtime enforcement is disconnected.
You need a runtime authorization decision that is scoped, enforced, and logged. Start with the smallest model that reflects real risk — often tenant-scoped RBAC with explicit resource permissions — then add ABAC, ReBAC, and stricter privileged/policy-admin controls as complexity grows. Centralize the model before it becomes unmanageable.
DORA and NIST are not vendor selection documents. They do not say "buy Permit." They do not require application FGA by name, and implementing Permit does not guarantee DORA compliance, NIST SP 800-53 satisfaction, or any certification.
Compliance depends on your full control environment: governance, risk management, incident response, vendor management, secure development, monitoring, resilience, evidence quality, and how controls are implemented and operated.
But the access-control direction is clear. DORA pushes scoped, limited, reviewable, and logged access across ICT systems. NIST SP 800-53 AC and AU push enforceable access control and accountable audit evidence. Emerging NIST NCCoE work around software and AI agents points the same way for non-human and delegated identities.
If the risk lives inside the application, the proof also has to come from inside the application. Product teams need authorization that can answer who or what acted; on whose behalf; against which tenant and resource; for which action; under which policy; with which result; and why.
That is what application fine-grained authorization is built to produce: scoped decisions and attributable logs. Not as a shortcut to compliance, and not as a replacement for IAM, GRC, or security operations — but as the application-layer control and evidence system those programs increasingly depend on.
Co-Founder / CEO at Permit.io
