Across everything your identity management tools own - access, authentication, authorization, and governance - the safe outcome should be built in by construction, not bolted on beside it.
The expensive identity breaches of the last few years share something unglamorous: almost nobody broke in. They've just logged in. In August 2025, one attacker group stole OAuth tokens from a single trusted integration - the Drift chatbot wired into Salesforce - and walked into the Salesforce environments of more than 700 organizations, several of them well-known security firms. No malware, no cracked password, just valid tokens against a door working exactly as configured. MFA never fired; the token was already trusted. The problem was not a missing lock. The lock was there and did its job - it just asked the same little of everyone, whatever lay behind the door. This is not a one-off - almost 70% of security incidents it investigated last year were identity-related weaknesses.
A valid token walks through a door working exactly as configured - no malware, no alarm, and MFA that never fired.
We've seen this problem in different places
I have seen this before, in a different domain. Before identity, I spent years in application security, a balancing act every security and engineering team knows: let developers ship fast while keeping dangerous code out of production. What worked was never a scanner off to the side, filing findings to read later; it was a gate inside the delivery pipeline that stopped risky code before it shipped, when the fix was one line instead of a live incident.
Access policy is the identity version of that gate: it sits in the path of every login, the one place to allow, deny, or step up when it matters. The scanner maps across too - its twin is the posture tool (ISPM), which flags under-protected accounts but sits beside the identity provider, not in it, so it only reports, never intervenes.
The stakes are higher here than in the pipeline: the gate no longer stands between developers and their code, but between your whole workforce - plus the AI agents now acting for them - and everything those identities can reach. Same principle, bigger blast radius. The rule is unchanged: put a smart, adaptive and holistic access policy in the path, with the context to know what it is protecting.
But hardening the door has a cost: every control that keeps attackers out is also friction on people, and now agents, with legitimate work to do. Tighten too far and the business stalls; ease off and the door can be opened easily. Everyone already ships a login policy, so that is no differentiator - the question is whether theirs is good enough to hold the balance: unified across people and agents, weighing what is being reached and scaling the proof to match.
A gate that fits what it guards
Most access policies handle the identity half well: who someone is, what team, whether the device is managed. They fall short on the other half - what a given application is worth to the business. The major identity providers do let you say it - some have "Crown Jewel" labels, others a "high sensitivity" tag or just allow you to customize it - but that worth is set by hand, once, at onboarding, and then it drifts: an app tagged "medium" on day one stays "medium" long after it quietly became the system your finance team closes the quarter on. This is not hypothetical: in 2024, attackers walked into the data warehouses of about 165 companies - Ticketmaster and Santander among them - just by reusing stolen passwords, because those instances never required MFA. The data was the business; the door was guarded like anything else.
The platform should carry that judgment instead - and it is the one system positioned to, because the signals that reveal an app's worth already pass through it. The proof it demands is not one setting: authenticators sit on a graded strength scale that NIST codifies, from a password (AAL1) to a phishing-resistant, hardware-bound key (AAL3). Then it can demand the level that fits, instead of the same factor on every door. And worth is not only per app - it is per privilege. The same Salesforce is one risk for a read-only rep and quite another for an admin who can export every customer record and rewire who sees what: that admin should have to clear a higher bar - a phishing-resistant AAL3 factor - than the reader, in the very same app. That is what a security-first access policy gives you:
- Put the business context where the decision is made. It should know what an app is worth - who signs in, in what roles, prod or sandbox, what data it holds - not just the user.
- Match the proof to the stakes, not the identity alone. Authentication strength scales to each app's criticality, so the strongest challenge lands on the system that moves money, not the app that books a meeting room.
- Make the safe outcome the default, not a setting. The baseline is safe by construction, and the most specific rule wins on its own - no dragging rules up a list, no gap left to be found.
- Let the policy decide on its own, in real time. It keeps watching the live session and acts the moment risk changes - stepping up for fresh proof or ending the session - instead of trusting a decision it made an hour ago.
The platform already knows what's at stake
Every signal the IdP sees at sign-in - who, likely data sensitivity, environment, scopes, reach - composes into a live criticality level that sets the proof a request must clear. No hand-set tag to go stale.
Signals weigh in, the level sets the bar.
No guessing, before or after
You should never have to guess who a policy change will hit - guessing is how the gaps in those breaches survived. Nobody chose to leave an account without MFA or a token over-permissioned; the gap just sat there until an attacker found it. Simulation is the refusal to guess: before a policy goes live, it runs against your real population and shows who sails through and who gets locked out, so you fix the gap in a preview, not an incident report. It works both ways - say "finance admins reaching the ledger need a phishing-resistant factor" and the platform turns that into policy, or trace how your rules resolve into what is enforced right now, and which one won.
Why it has to be built in
The posture tool can flag the gap; it cannot close it, because it is not there when someone signs in. Detection is always after the fact. A policy in the path is the opposite: it is opinionated - it refuses the unsafe configuration and steers you toward the safer one, instead of leaving you to clean up later. Only the identity provider is in that path, and only if it carries the context to decide in proportion. Security cannot be a layer you add later; it has to be the spine.
That is what we are building NewCore on: an identity platform whose access policy is security-first by construction, on secured infrastructure (Secure Split Key) with stronger authenticators (i.e. device-bound synced passkeys) for people and agents alike. Security stops being the tax you pay for access and becomes what lets the business say yes faster, because friction lands only where it is earned.