Authentication confirms who or what received access. Runtime authorisation decides what that identity can do after the session starts, including whether it can reach a schema, modify a table, or invoke a destructive action under current conditions.
Authentication vs runtime authorisation in data access
Authentication is the identity check at the front door. runtime authorisation is the decision engine inside the session that keeps checking whether the authenticated subject may read this dataset, write that table, or call this operation right now. The distinction matters because a valid login does not imply ongoing permission to every object, action, or environment.
How the two controls split the security problem
Authentication answers who or what is present. It establishes that the actor is the one that was enrolled, issued credentials, or otherwise trusted enough to start a session. In a data platform, that can be a human analyst, an application, a workload, or a service account. Once that initial trust is established, the system still needs a separate check for each meaningful access decision.
Runtime authorisation answers what this actor can do under the current conditions. That can include row-level access, schema visibility, DML versus read-only actions, temporary elevation, network location, time of day, transaction context, or whether a destructive action needs step-up approval. The control is dynamic because the same identity may be allowed one operation and denied another without changing who it is.
This split is why a database can authenticate a client successfully yet still block the query. The session may be valid, but the current policy may not permit the target table, the requested column set, or the write path. That is also why many platforms separate login, token validation, and permission evaluation from the data-plane decision itself.
Why this distinction matters for data systems
In practice, most serious failures happen when teams treat authentication as if it were enough to protect the data layer. A logged-in session can still be over-privileged, mis-scoped, or operating with stale rights. Good runtime authorisation limits the blast radius by enforcing least privilege at the moment of use, not just at sign-in.
For access to data, the strongest designs treat authorisation as a policy decision that can vary by object, action, and context. That is especially important when the same account can reach multiple schemas, service endpoints, or administrative functions. Authorisation models matter here because coarse role assignment often needs help from attribute- or relationship-based checks when access must be evaluated continuously.
When runtime checks are missing or too shallow, attackers and insiders benefit from the gap between “allowed to log in” and “allowed to do this action.” For API-backed data access, that gap often appears as broken object-level or function-level authorisation, where a valid caller can reach records or operations it should not be able to use.
Risk and Threat Considerations
The main risk is assuming that a successful authentication event means the session is safe for all later actions. If authorisation is only handled at login time, stolen credentials, session replay, or over-broad service permissions can turn a single authenticated foothold into broad data exposure or destructive write access.
Failure mechanism: An identity authenticates once, then the application, database, or API fails to re-evaluate the exact object, action, or context at the moment of access. That allows privilege to persist beyond what the current request should receive, especially after role changes, token theft, or policy drift.
Impact: The result can be unauthorized reads, lateral movement across schemas or tenants, hidden write capability, or destructive actions executed under a valid session. In stronger breach cases, attackers use authenticated access as a springboard to harvest data or escalate from normal user operations to administrative control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Data access here turns on enforcing what an authenticated session may do. |
| Recommendation — Verify object-, action- and context-level checks before any data operation is allowed. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Runtime authorisation should limit active permissions to only what the request needs. |
| IA-2 — Identification and Authentication (Organizational Users) | Authentication establishes who or what is present before any authorisation decision can occur. | |
| IA-9 — Service Identification and Authentication | Runtime data access often involves services and workloads that must authenticate before policy evaluation. | |
| Recommendation — Apply least privilege so each session can only perform the data actions it is explicitly allowed to do. Authenticate the user or service before authorising access to data resources. Authenticate service-to-service calls before evaluating their permitted data actions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question distinguishes initial identity proof from ongoing access decisions. |
| Recommendation — Define and enforce access rules that separate login from permitted data operations. | ||
Practitioner Guidance
What to verify: Check whether your platform enforces authorisation at the data object and action level, not just at login. A good test is whether the same authenticated session can be denied one table, one row set, or one destructive verb while still remaining valid for other permitted reads.
Decision rule: If the access decision can change based on the resource, action, or runtime context, treat authorisation as a live control path, not a one-time gate. If it cannot be re-evaluated after sign-in, assume the session is carrying more authority than you intend.
Practitioner takeaway: Authentication establishes trust in the session, but runtime authorisation is what keeps that trust constrained to the specific data operation being requested.
Related resources from NHI Mgmt Group
- What is the difference between protecting data with encryption and protecting access with authentication in financial services?
- What is the difference between compliance evidence and runtime access control?
- What is the difference between encryption and access control in AWS data protection?
- What is the difference between agent authentication and agent authorisation?