Every Breach Starts
with a Permission
Nobody Revoked
Eighty percent of confirmed breaches begin with a compromised credential carrying permissions it should never have had. The tools built to find those permissions are disappearing from the market. The permissions are not. This piece lays out why, and what a purpose-built response now requires.
Enterprises have spent the last decade fortifying networks and endpoints. The investment was necessary. But while those defences matured, the permissions attached to every human and machine identity across every cloud grew unchecked: unaudited, unmeasured, quietly accumulating the kind of access that turns a compromised credential into a catastrophic breach.
When the Market Moved On
In July 2021, Microsoft acquired CloudKnox Security for a reported $500 million, a clear signal that the industry’s largest cloud vendor considered multicloud identity governance a strategic priority. CloudKnox had built one of the few platforms capable of mapping and right-sizing permissions across Azure, AWS, and GCP simultaneously. It became Entra Permissions Management, the only standalone CIEM tool in the Microsoft portfolio.
For three years, it offered cross-cloud permission analytics, usage-based right-sizing, and a single pane for identity posture across three hyperscalers. Then, in November 2025, Microsoft made a strategic decision to consolidate its security portfolio and retired the standalone product. Existing customers were directed to CIEM capabilities within Microsoft Defender for Cloud and to partner solutions.
The decision was understandable. Platform vendors routinely consolidate to reduce portfolio complexity. But the consolidation left a gap. The standalone tool that addressed multicloud identity governance as a first-class discipline, independent of a broader security suite, no longer had a successor. The capabilities folded into Defender for Cloud serve a different scope. The third-party alternatives bundle CIEM into platform deals that start well above six figures.
The problem that justified a $500 million acquisition has not gone anywhere. Permission creep follows a pattern that every security team recognises but few can quantify. A developer receives Contributor access to a resource group for a three-month project. The project ships. The access stays. A service principal is granted Owner rights to run a data migration. The migration completes in a week. Eleven months later, that principal still holds its original access across three production subscriptions.
Multiply those micro-decisions across thousands of identities, three or more cloud providers, and several years of accumulated role assignments. The result is an attack surface that no perimeter defence can reach, because it lives inside the perimeter.
“The most dangerous permission in any enterprise is the one nobody remembers granting.”
— Lawrance Reddy, Cloud CTO, VaxowaveCredentials and permissions are the primary entry point for four in five confirmed breaches
Organisations do not lack identity providers. What they lack is visibility into the permissions those identities accumulate over time: the project access that was never revoked, the migration credentials that outlived the migration, the temporary workarounds that became permanent by neglect.
What a Single Identity Can Reach
Abstract risk is easy to dismiss. A specific identity is not.
A service principal was created in March 2024 to support a storage migration between two Azure subscriptions. The migration team provisioned it with Storage Blob Data Owner and Key Vault Crypto Officer across three production subscriptions. The migration completed in nine days.
Fourteen months later, the principal still holds both roles. It has not authenticated since April 2024. No alert was generated. No access review flagged it. The principal does not appear in any team’s operational runbooks, because the team that created it has since reorganised.
If this credential is compromised tomorrow, the attacker inherits read and write access to every storage blob and every encryption key across three production subscriptions. Not the access the principal needs. The access it was once given. The blast radius is not theoretical. It is measurable, and it is large.
This is not an unusual finding. It is the finding, repeated across hundreds of identities, in every environment we have assessed.
Most organisations cannot answer a basic question about any given identity: what is the gap between the permissions it holds and the permissions it actually uses? Without that answer, right-sizing is guesswork. Remediation is reactive. Audit responses become exercises in reconstruction rather than evidence.
For regulated enterprises in financial services, healthcare, government, and critical infrastructure, the compliance dimension is not abstract. Whether the framework is SOC 2, NIST 800-53, PCI-DSS, GDPR, POPIA, or sector-specific mandates from banking regulators, the expectation is converging: demonstrate that access to sensitive data is justified, periodically reviewed, and revocable on demand. A permission estate that has never been measured cannot produce that evidence. It can only produce narratives, and narratives are not surviving audit cycles the way they once did.
What the Market Offers — and Where It Falls Short
With the retirement of Entra Permissions Management, cross-cloud CIEM capabilities are now available primarily as modules within larger security platforms. Procurement requires committing to a full suite (cloud security posture management, workload protection, endpoint detection) to access the identity governance capability buried within it. Pricing reflects the breadth of the bundle, not the depth of any single discipline.
For an enterprise that needs multicloud identity governance specifically, the market presents a stark choice: buy a platform you do not need to access the module you do, or go without.
This is the gap VIPP was built to close. Visibility into Identity Permissions & Posture is a purpose-built multicloud CIEM platform: procurable independently, designed around the principle that identity data should never leave the tenant that owns it, and engineered to do a single discipline well. The following questions separate genuine capability from marketing claims.
| The question | The industry norm | How VIPP answers it |
|---|---|---|
| Can an auditor verify how risk scores are calculated? | Most CIEM tools treat scoring formulas as proprietary. A score appears on a dashboard. The methodology behind it is not disclosed or verifiable. | Published multi-factor formula. Every variable documented, every weight visible. Auditors verify the methodology independently, without requesting vendor documentation. |
| Can you procure identity governance without buying an entire security suite? | CIEM is typically bundled into CNAPP or endpoint security platforms. Standalone procurement is rare, and pricing for the bundle commonly starts above $50K per year. | Purpose-built standalone CIEM. Procurable independently at a fraction of the cost of bundled alternatives. Identity governance is the product, not a feature. |
| Does your identity data stay within your own infrastructure? | Most CIEM platforms are SaaS-only. Permission data, sign-in logs, and usage telemetry are processed and stored in the vendor’s cloud. | Deploys into your Azure subscription. Identity data never leaves your tenant boundary. No vendor-side processing. No telemetry exfiltration path. The architecture enforces data sovereignty by design. |
| How broad is the actual platform coverage? | Typical coverage spans 3 to 5 cloud providers. Identity sprawl across SaaS platforms (Kubernetes, Okta, GitHub, Snowflake, ServiceNow) is largely unaddressed. | Deep integration across Azure, AWS, and GCP at launch. Connector library expanding to Kubernetes, Okta, GitHub, Salesforce, ServiceNow, Snowflake, and Databricks. |
| Is AI investigation contextual, or bolted on? | AI assistants are increasingly common but typically operate as separate panels, disconnected from the identity context of the page you are viewing. | Vigil is embedded on every page with full identity context, powered by a frontier language model hosted entirely within your Azure tenant. Queries never leave your environment. |
| How does the platform authenticate to your clouds? | API keys or service account credentials are typically required and stored within the vendor’s platform. | Federated identity for every major cloud. Managed Identity for Azure. Workload Identity Federation (OIDC) for AWS and GCP. No stored credentials for any hyperscaler. |
| Is just-in-time access elevation built in? | JIT support varies widely. Some platforms offer it natively, others through integrations, some not at all. | Full JIT workflow: request, approve, grant, auto-revoke. Time-bound elevation with complete audit trail. No external integration required. |
A Platform Built for One Problem
The gap in the market is not a feature gap. CSPM platforms offer permission inventories. PAM solutions manage privileged sessions. IAM platforms provision and deprovision access. None of these address the specific discipline of continuous, cross-cloud permission creep governance: discovering every identity, measuring the gap between what it holds and what it uses, and closing that gap without breaking the workflows that depend on it.
VIPP was built for that discipline. Not as a module inside a platform. Not as a feature in a bundle. As a standalone product, purpose-built for multicloud identity governance, built and tested end-to-end, and ready to integrate. Seven compliance frameworks. Expanding connector library. Currently being deployed into banking and financial services environments where data sovereignty and regulatory compliance are non-negotiable.
VIPP — Visibility into Identity Permissions & Posture. One platform that discovers every identity across your clouds, scores its risk transparently, remediates the excess, and governs what remains.
Discover
Continuous enumeration of every identity, role assignment, and permission across Azure, AWS, and GCP. Human and machine. Cross-referenced against actual usage telemetry. Expanding connector library covers Kubernetes, Okta, GitHub, Salesforce, ServiceNow, Snowflake, and Databricks.
Score
Every identity receives a Permission Creep Index, a transparent, multi-factor score that quantifies the gap between granted and used permissions. Deterministic. Auditable. The same inputs always produce the same output. Boards can track it. Auditors can verify it.
Remediate
Context-aware right-sizing recommendations based on observed usage patterns. Automated workflows for removing excessive permissions with configurable approval gates and rollback. Just-in-time access elevation with time-bound grants and full audit trail.
Govern
Seven compliance frameworks mapped against identity posture: SOC 2, ISO 27001, PCI-DSS, NIST 800-53, GDPR, POPIA, and CIS Benchmarks. Continuous drift detection. AI-powered executive briefings generated on demand.
The Formula Is the Contract
Most identity security tools that generate a risk score guard the formula as proprietary. A number appears on a dashboard. A SOC analyst sees “High Risk.” The auditor asks how the score was derived. Nobody can answer with precision. Opaque scoring is not governance. It is an assertion without evidence, and it does not survive an audit committee that asks follow-up questions.
VIPP’s Permission Creep Index is deterministic. The same inputs always produce the same score. Every factor is documented, every weight is published, and the arithmetic is verifiable by anyone with access to the dashboard.
That identity, a service principal with 47 role assignments across two Azure subscriptions and an AWS account, scored 72. The score reflects four visible factors: 83% of granted permissions are unused, three of those unused roles carry administrative-level sensitivity, the average idle period across unused permissions is 58 days, and the identity is approaching the dormancy threshold.
A CISO reviewing this identity in an audit committee can explain precisely why it scored what it did, what changed since the last measurement, and what remediation was taken. The formula is the contract between the platform and the people accountable for the results.
Investigation That Starts Where Manual Correlation Ends
An enterprise with tens of thousands of identities across multiple clouds generates millions of permission data points. No analyst can manually trace the blast radius of a compromised service principal across nested role assignments, group memberships, and inherited scopes. The data exists. The human bandwidth to interpret it does not.
Without Vigil: A SOC analyst receives an alert flagging a service principal in a production AWS account for permission anomaly. Investigating the blast radius means cross-referencing the principal’s role assignments in IAM, checking CloudTrail for recent API calls, mapping inherited permissions through group memberships, and estimating the scope of resources at risk. In a complex environment, this takes between two and four hours before the analyst can make an informed decision.
With Vigil: The analyst types: “Show me the full blast radius for this principal, including inherited permissions and every resource it can reach.” Vigil returns the answer in seconds: 23 resources accessible directly, 7 reachable through group inheritance, 4 encryption keys within scope. It generates a remediation plan: 6 role assignments to remove immediately, 3 to downgrade, 2 to flag for team review. The analyst’s decision starts where the data synthesis ends.
Vigil is an investigation engine embedded on every page, powered by a frontier language model running inside your Azure tenant, with full context of the identity data it reasons about.
- Natural language queries across the entire identity estate. No query language to learn, no context-switching between tools
- Blast radius analysis for any identity, mapping the full scope of what a compromised credential could reach across clouds
- On-demand executive briefings with risk trends, posture changes, and remediation progress, filterable by cloud, account, or organisational unit
- Remediation plans generated with context: what to remove, what to downgrade, what to escalate for review
- Compliance posture summaries mapped against any of the seven supported frameworks
Vigil runs entirely within your tenant. Queries, briefings, remediation plans: all processed locally, against your data, with no calls to external inference endpoints. The intelligence is yours. So is every byte of data it reasons about.
Your Data Never Leaves. By Design.
Most identity security platforms require your permission data (role assignments, sign-in events, usage logs) to transit to the vendor’s infrastructure for processing. For a technology company, that trade-off may be acceptable. For a financial institution under banking regulations, a healthcare provider under HIPAA, or any enterprise subject to data residency mandates in the EU, Middle East, Africa, or Asia-Pacific, it is a non-starter.
VIPP was architected around a different principle: identity data belongs to the organisation that owns it. The platform deploys into your Azure subscription, in your region, behind your network controls. The permission data it collects, the scores it calculates, the alerts it generates, the compliance reports it produces. None of it leaves your tenant boundary. No vendor-side processing. No telemetry exfiltration path. No shared tenancy. Regardless of how VIPP is delivered, the architecture guarantees that your identity data stays exactly where it belongs: with you.
Underneath, the platform runs on enterprise-grade PaaS services: globally distributed databases, premium messaging infrastructure, dedicated compute with private networking, AI inference, real-time analytics, and comprehensive observability. Every service communicates over private endpoints within a locked virtual network. The only public surface area is a single WAF-protected ingress.
Zero Stored Credentials
Managed Identity within Azure. Workload Identity Federation (OIDC) for AWS and GCP. No API keys. No service account passwords. No stored secrets for any hyperscaler. SaaS platform credentials managed via enterprise vault with automatic rotation.
Infrastructure as Code
The entire platform deploys from a single command via Bicep modules: auditable, version-controlled, reproducible. No portal-click configurations. No undocumented steps. Tear down and redeploy in under an hour.
Private by Default
Every Azure service deployed with private endpoints. No public-facing databases, message brokers, or AI inference endpoints. Network isolation is the default posture, not an optional hardening step.
Region-Locked Deployment
Deploy to the region your regulator requires: EU, US, Middle East, Africa, Asia-Pacific. The infrastructure respects data residency by design. No cross-region replication unless you configure it.
Your Tenant. Your Data. Your Keys.
Scores, alerts, audit logs, compliance reports, AI inference. All generated and stored within your tenant boundary. The architecture enforces this regardless of deployment model. VIPP was designed around that principle from the first line of code.
You Already Know the Risk Exists
The question has never been whether excessive permissions are a problem. The question is whether you can measure yours, explain them to an auditor, and remediate them before they are exploited. If the answer to any of those is not yet, that is the conversation worth having.
