Topic starter
11/10/2026 6:56 pm
TL;DR: PlainID says enterprise authentication solved the “who are you?” problem, but runtime access remained hard to control across siloed technologies as human and non-human identities multiplied. The governance challenge is no longer entry alone, but what each identity can do once inside.
Editorial analysis by NHI Mgmt Group, based on content published by PlainID: “Go Beyond Who Gets In.”.
Key questions
Q: How should security teams implement runtime authorization in identity security programmes?
A: Security teams should move the final allow-or-deny decision out of application code and into a dedicated policy layer that evaluates identity, resource, action, and context at request time.
Q: Why does authentication alone fail to control access in modern applications?
A: Authentication proves an identity, but it does not govern the actions that identity can take once inside the application.
Q: What are the signs that application authorization is becoming unmanageable?
A: Common warning signs include growing numbers of roles, permissions, and environment specific exceptions, plus repeated if/then/else logic scattered through code.
Practitioner guidance
- Define runtime decision points Identify where applications currently make allow or deny decisions locally and mark those paths for external policy enforcement.
- Separate authentication from authorization Review application designs so proof of identity and permission to act are controlled by different mechanisms and ownership models.
- Classify access by identity type Map human users, partners, customers, service accounts, and automated identities to distinct authorization rules instead of a shared entitlement pattern.
Bottom line: Authentication and authorization are no longer separable operational concerns in large estates, because runtime decisions define the real exposure surface.
What's in the full article
PlainID's full overview covers the operational detail this post intentionally leaves for the source:
- The company story behind the runtime authorization platform and why its founders say existing access models fell short
- Enterprise use cases for controlling what identities can access, do, and expose across mixed application stacks
- Details on the scale claim around securing over 35 million identities and processing billions of authorization decisions daily
- Leadership and funding background that explains how the vendor positions its enterprise transition
👉 Read PlainID's overview of runtime authorization for mixed identity environments →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/10/2026 6:57 pm
Runtime authorization is the real control plane when authentication no longer differentiates risk. The article reflects a mature identity problem: access is granted too early in the stack to be the only meaningful control. Once human and non-human identities enter the application, the more important question is what they can do, not simply whether they arrived with valid credentials. Practitioners should treat authorization as an always-on governance layer, not an application afterthought.
A question worth separating out:
Q: What is the difference between authentication and runtime authorisation for data access?
A: 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.
👉 Read our full editorial: Runtime authorization for exploding identity estates