The Shared Responsibility Model & Why it Matters

What is the shared responsibility model for identity?

The shared responsibility model for identity splits accountability between the identity provider and the customer. Okta and Microsoft Entra ID guarantee that their service stays up. You guarantee that your tenant configurations, policies, users, and non-human identities are backed up, validated, and recoverable when something breaks.

The Shared Responsibility Model in Plain Terms

Every cloud service runs on a contract. The provider promises that their service is available, secure at the infrastructure level, and patched on schedule. You, the customer, promise that everything you put inside that service is configured correctly, backed up, and recoverable when something goes wrong. That is the shared responsibility model in one sentence. Most security teams absorbed it for infrastructure over a decade of cloud migration. Almost none have absorbed it for identity, and the gap shows up in every IAM incident, audit, and AI deployment plan.

Here is the version that matters for identity, stated plainly. Your identity provider guarantees its own uptime, not your ability to recover your tenant. If Okta's service stays up but a misconfigured policy push locks out 10,000 of your users, that incident is yours to fix. If Microsoft Entra ID's authentication endpoints stay healthy but a ransomware operator encrypts your Conditional Access configuration, the cleanup belongs to you. The IDP did its job. The configuration state inside your tenant did not, and nobody at Okta or Microsoft is going to restore it.

This is the recoverability gap. It is the structural distance between what your IDP contract actually covers and what your security, compliance, and operations teams assume it covers. The gap is not a bug in the contract. It is the contract. The cloud IDP model was built so the provider could operate a multi-tenant platform at scale without being on the hook for what every customer does inside their tenant. That tradeoff makes the cloud work. It also creates an obligation very few teams have explicitly built for.

The gap is the foundation of the IAM Resilience category, and the reason Acsense exists.

The IDP runs the service. You run the tenant. Most teams discover the line on the day they need to cross it.

What Okta and Microsoft Actually Say

The cleanest way to understand the model is to read what each IDP publishes. Both have explicit positions. Both are unambiguous about what they own and what you own. The two positions are remarkably similar in shape, which is the point. The mirror is not a coincidence: it reflects how every cloud IDP draws the line.

The IDPs guarantee the service. The customer guarantees the tenant.

Read those two side by side and the pattern is impossible to miss. The IDP owns the service. You own the configuration. The two providers use different words to describe the same split. Neither is breaking the contract. Your side is just a lot bigger than most teams realize on the day they sign.

Where the Analogy Came From, and Where It Breaks

The shared responsibility model started with infrastructure. AWS made it famous with a simple split: security of the cloud belongs to AWS, security in the cloud belongs to the customer. Azure and Google Cloud followed the same pattern. Every SaaS contract you sign now inherits the framing.

The cognitive trap is assuming the IaaS framing maps cleanly onto identity. It does not. In IaaS, the customer controls the operating system, the runtime, and the data. They have root. They can install whatever backup tooling, configuration management, and recovery automation they want. In identity, the customer controls the configuration layer of a service the provider operates end to end. You do not have root on Okta or Entra ID. You cannot install a backup agent or snapshot the tenant the way you would snapshot a virtual machine. The line moves up in the stack, but the recovery obligation does not shrink. If anything, it grows, because you have fewer native tools to back up and restore configuration state than you would on a server you fully own.

This is the part that surprises experienced cloud teams. They have built mature recovery practices for EC2, S3, RDS, AKS, and every other IaaS or PaaS service they run, then assume the same maturity exists for identity because identity feels like just another SaaS. It is not. Identity is the access layer for everything else. When it breaks, every other system that depends on it stops working. And the native restore primitives the IDP offers are designed to recover deleted objects, not configuration state, not policy state, not the dependency graph that connects users, groups, applications, and non-human identities into a working tenant.

Okta and Microsoft both honor the contract. The problem is that most enterprises have not built the customer side for identity the way they built it for infrastructure. The IaaS version arrived with a decade of tooling and operational pattern language. The identity version arrived without any of that, and the regulatory consequences are catching up faster than the tooling.

The Four Moments Enterprises Discover the Gap

The recoverability gap is invisible right up until it isn't. Most enterprises do not discover their side of the shared responsibility contract by reading it. They discover it during one of four moments, and by then the conversation is no longer hypothetical.

Why AI Agents and NHIs Are Redrawing the Line

The shared responsibility model was originally written for a world where the customer side meant human users, their policies, and the applications they accessed. That world is gone, and the model has not been rewritten. The line between provider and customer is the same. What sits on the customer side has expanded by an order of magnitude.

Non-human identities now outnumber human identities in most enterprise environments by ratios of 10:1 to 45:1. Service principals, OAuth tokens, API keys, workload identities, automated workflows with their own credentials, and AI agents that authenticate to call APIs, read data, and modify systems on their own behalf. Every one of these is an identity the IDP recognizes. Every one carries permissions, token scopes, group memberships, and configuration state. Every one is subject to the same compliance frameworks human identities are. And every one sits on the customer side of the contract.

The IDP guarantees the authentication service is available for your AI agent. The IDP does not back up the agent's identity binding, its OAuth scopes, or the role assignments it depends on. When those break or drift, the agent either stops working or operates with wrong permissions. Either way, recovery belongs to the customer.

Three forces are converging to make this acute. The identity surface is expanding exponentially: every new AI agent, automated workflow, and SaaS integration adds NHI configuration state to the customer side of the contract, and most organizations are protecting almost none of it. NHIs are harder to audit than humans because they do not have managers who notice when MFA goes missing, do not get offboarded when projects end, and proliferate without centralized visibility. And attackers know this. Threat actors target service accounts and tokens because they are less monitored, rarely rotated, and often over-privileged. Post-compromise, they modify NHI configurations to persist: adding OAuth applications, expanding scopes, quietly elevating service principals. That modification is configuration drift on your side of the contract, invisible to anyone not continuously comparing the live state to an approved baseline.

The bottom line is the one that should keep CISOs and CIOs awake. The organizations deploying AI agents most aggressively are the ones with the largest customer-side recoverability gap. The agents work today. The gap shows up the first time an integration breaks, an auditor asks for evidence, or an attacker uses the NHI surface as a persistence layer.

How Acsense Completes the Customer Side

Not evidence collection. Enforcement. Acsense does not compete with Okta or Microsoft. Acsense is what the customer side of the shared responsibility contract looks like when it is built deliberately, end to end, across both IDPs. The IAM Resilience Platform delivers four integrated capabilities that map directly to the obligations the IDP contract places on you, unified under one baseline, one runbook, and one evidence trail.

The cleanest way to think about how the platform works is the three-part loop the Compliance and Assurance capability runs continuously, and that the rest of the platform reinforces. Detect what is happening. Enforce the approved state. Prove the result to anyone who asks.

Detect

Continuous backup and incremental synchronization compare the live state of your Okta and Entra ID tenants against an approved baseline. Configuration drift is flagged in 10 minutes or less. Alerts route to Slack, Teams, SIEM, and email. Time Machine gives you a full change history across every object and policy: who changed what, when, and from what state. Recoverability Health surfaces backup completeness and restore risk before an incident, not after. Drift on the human identity side and drift on the NHI side both show up in the same view, because the customer side of the contract makes no distinction between them.

Enforce

Detection without enforcement is just monitoring. Acsense restores IAM configurations to approved compliant states when drift is detected. Conditional Access policies roll back to the last known-good version. Unauthorized OAuth registrations are killed. Privilege escalations are reverted. Full tenant rollback brings the entire environment back to any prior point in time. Hot standby tenants and one-click failover handle the disaster-recovery scenarios where the production tenant is unreachable. Continuous Resilience Validation runs automated DR drills in the background and produces auditable proof of recovery readiness, so you never have to hope your recovery plan works. Other tools alert. Acsense restores.

Prove

Acsense maps live configuration state against SOC 2, ISO 27001, NIST SP 800-53, HIPAA, GDPR, DORA, NIS2, and APRA CPS 230/234 in real time. Automated compliance scoring, historical configuration logs, and audit-ready evidence replace weeks of manual spreadsheet collection. Non-human identity audit trails cover AI agents, service principals, OAuth apps, managed identities, and API tokens across both IDPs. Not threat indicators. Not security scores. The actual controls your audit firm checks, mapped to the configurations running in production right now.

One Platform. Any IDP. One Baseline.

IDP-agnostic by design. Acsense currently supports Okta and Microsoft Entra ID, with more identity providers on the roadmap, under a single compliance baseline, a single recovery runbook, and a single audit-evidence trail. Environments that run both IDPs today get one platform instead of two. Environments that are single-IDP today get architecture that is ready when the second IDP arrives through M&A, cloud migration, or a CIAM rollout.

This reframes the buyer's question. It is no longer "do I need another tool?" It is "how am I fulfilling the contract my IDP already published?" The IDPs guarantee their own uptime. Acsense guarantees yours.

Where to Start

If your organization has not explicitly built the customer side of the shared responsibility model for identity, the first step is to stop pretending the IDP handles it. The second is to inventory the obligations you have already signed up for and rank them by how exposed you are today. The order is consistent across industries and frameworks:

• Read your Okta and Entra ID contracts. Identify every customer-side obligation in plain language.
• Document your current IAM recovery process end to end. If the document does not exist, write a first draft from memory. The gaps will surface immediately.
• Inventory your non-human identities. Service principals, OAuth applications, API tokens, AI agent bindings. Map who owns each one and what it can do.
• Identify which compliance frameworks apply to your IAM environment. SOC 2, ISO 27001, HIPAA, DORA, NIS2, APRA CPS 230, NIST SP 800-53. Pin each to a specific control set.
• Deploy continuous backup for tenant configuration across both IDPs. Object data, configuration state, workflows, integrations, policies, and assignments.
• Stand up drift detection with 10-minute alerting. Across Okta and Entra ID. Cover human and non-human identities together.
• Define and test RTO and RPO for identity infrastructure. Run the recovery drill. Document the result. Repeat quarterly.
• Map live configurations to your applicable frameworks. Build the audit-evidence pipeline once. Maintain it continuously.

None of these steps require a vendor selection. All of them start to close the gap immediately. When manual work outweighs the gain, that is when a purpose-built IAM Resilience Platform earns its keep.

---

Frequently Asked Questions

What is the shared responsibility model for Okta?

Okta is responsible for platform availability, infrastructure security, service-level patching, and regional redundancy of the Okta service itself. The customer is responsible for tenant configuration integrity, user and group data, MFA and sign-on policies, application assignments, workflows, directory integrations, and the backup and recovery of tenant state. If your tenant gets misconfigured, deleted, or compromised, Okta restores the service, not your configuration.

What is the shared responsibility model for Microsoft Entra ID?

Microsoft is responsible for service availability, platform security, physical infrastructure, regional redundancy, and identity-platform patching. The customer is responsible for tenant data, directory objects, Conditional Access policies, application registrations, service principals, group memberships, and recovery of deleted or corrupted objects. Microsoft's own guidance states that they do not back up customer Entra ID data in a way that supports customer-initiated recovery beyond short soft-delete windows.

Who is responsible for recovering my Okta tenant if it gets misconfigured?

The customer is. Under Okta's shared responsibility model, recovery of tenant configuration, policies, users, groups, and integrations sits squarely on the customer side. Okta's system log retains event data for 90 days as a forensic record, not as a restore mechanism. Without a third-party recovery platform such as an IAM Resilience Platform, the practical options are manual rebuild from documentation or hoping nothing important was lost.

Does Microsoft back up my Entra ID configuration?

No, not in the sense most teams assume. Entra ID provides a soft-delete window for deleted users and groups (typically 30 days) and a recycle bin for some object types. Configuration state, Conditional Access policies, application registrations, and service principal permissions are the customer's responsibility to back up and restore. Microsoft's documentation is explicit on this point.

How does shared responsibility apply to AI agents and service accounts?

AI agents, service principals, and OAuth tokens are non-human identities, and they sit on the customer side of the shared responsibility model. Each one carries permissions, token scopes, and configuration state that the IDP does not back up for you. NHIs now outnumber human identities by more than 80 to 1 in the average enterprise, with some research showing ratios as high as 100 to 1, and they are the fastest-growing recoverability gap. When an AI agent's identity bindings drift, the agent stops working or operates with wrong permissions. The customer owns that recovery. See why non-human identities require IAM Resilience for the full breakdown, and what the AWS outage teaches about IAM Resilience and shared responsibility as a related read.