For years, enterprise security has been about building stronger network perimeters, patching vulnerabilities and keeping malicious software out of corporate systems. But as more of a business’s operations move to cloud platforms and interconnected applications, the definition of a security breach is changing.
An attacker doesn’t necessarily have to exploit a software vulnerability anymore to get to sensitive enterprise data. An employee identity being compromised is, once again, all that it takes to have access to a trusted application and work within the permissions already granted to that account, creating a serious security incident.
Atul Luthra, CEO, Zeroday Ops & Co-Founder, 5Tattva
One example is the cyber incident reported in August 2026 by US healthcare company McKesson. The company said that some third-party applications had been accessed without authorization and that data related to a subset of customers across its oncology, multispecialty and medical-surgical businesses had been exfiltrated. The company said its core distribution businesses were not affected. ShinyHunters claimed responsibility for the attack, saying it gained access through voice phishing, but McKesson did not confirm the group’s version of events.
The larger lesson for enterprise security leaders is not limited to healthcare. This is about the increasing tension between giving trusted users access and continuously checking whether the access is being used legitimately.
When a trusted identity becomes the attack surface
Traditional security controls are, in part, intended to distinguish between authorised users and unauthorised actors. But once an attacker has access to a real account, it’s harder to make that distinction.
That’s the vulnerability that voice phishing – or vishing – exploits, tricking employees into giving away credentials or approving authentication requests. IT support staff could impersonate you, create a false sense of urgency, or trick employees into bypassing normal verification processes.
It’s not only the first compromise that’s in jeopardy. Single identity for access to multiple applications, data sets, and business workflows across connected cloud environments. If one account is compromised and permissions are too broad or authentication controls are weak, there are other ways to access data.
This shifts the question security teams should be asking. You need to verify that the user is authenticated right. Organizations will also have to assess whether the access being requested, the activity being performed and the data being accessed is consistent with legitimate business needs.
The SaaS connection: Why one compromise can have a wider impact
Enterprise apps are increasingly connected by single sign-on, APIs and shared identity systems. They provide ease of access and productivity for employees but they concentrate risk.
The third party app doesn’t even need to be compromised with a software flaw to be part of an attack chain. Or an attacker might exploit stolen credentials, misconfigured permissions, or an integration that is too trusted. This is important because organizations tend to measure security controls on a per-application basis whereas attackers will look for the easiest path across the environment.
Security teams need insight into how identities map to cloud applications, what data those applications can access and what permissions govern the flow of data between systems. Third-party assessments should move beyond vendor certifications and initial procurement checks to include ongoing monitoring, access reviews and incident response arrangements.
Organizations should also have processes for revoking access to connected services if an account or integration is suspected of being compromised.
Why multifactor authentication is not the end of the conversation
Multifactor authentication is an important security control, but how effective it is depending on the implementation and on how you handle authentication requests.
The social engineering can deceive the employees into approving fraudulent requests or sharing authentication information. Organizations should therefore implement phishing-resistant authentication for sensitive accounts and privileged access, use conditional access policies, and monitor for unusual login activity.
Identity security also must consider what occurs after authentication. When a legitimate account downloads unusually large volumes of data, accesses unfamiliar applications or changes permissions, that should trigger an investigation.
Behavioral analytics can help security teams to understand these patterns, but detection must go hand in hand with a documented response. Teams need to understand when to shut down sessions, turn off accounts, limit access to applications, and look into potential data exposure.
The idea is to stop a compromised identity from becoming a free-for-all path through your network, enabling lateral movement and access to sensitive data.
From security alerts to incident readiness
An organization can be well defended, but it cannot assume that all attacks will be stopped. How quickly they identify suspicious activity and take decisive action is critical to limiting damage.
Security teams must regularly test their ability to correlate identity, endpoint, and cloud application logs to piece together an attack. They should also practice scenarios involving compromised employee credentials, access to third-party applications and suspected data exfiltration.
The exercises will need to include more than the security operations center. Clear responsibility for IT teams, application owners, legal teams, business leaders and relevant vendors is critical – especially where an incident involves sensitive customer data.
The real measure of readiness is how quickly one can identify the affected identity, assess the scope of its access, contain suspicious activity and understand what data may have been exposed. Without these capabilities, organizations may have security tools that alert, but no timely coordinated response.
The questions every CISO should be asking
The lessons from incidents such as McKesson’s can be translated into a focused set of questions for enterprise security leaders. Organisations must assess whether they can detect and contain a compromised employee account before it is used to access additional systems, and ensure that connected cloud applications have only the permissions necessary for their business purposes. They must also evaluate whether access granted to vendors and third-party applications can be reviewed, restricted and revoked quickly. Equally important is the ability to identify unusual access patterns or the extraction of sensitive information, even when the activity originates from a legitimate account. Finally, organisations should regularly test their incident response capabilities through realistic exercises, with clearly defined responsibilities across security, IT and business teams.
These questions shift the focus from the number of security tools deployed to the effectiveness of the controls working together.
Security must be measured beyond prevention
In the next phase of enterprise cybersecurity, organizations will move beyond perimeter protection and assess the interactions of identities, applications, permissions and data.
The McKesson incident reminds us that an attacker may not necessarily get into a breach in the first place by directly attacking an organization’s core infrastructure, but by leveraging a trusted account and an interconnected application environment.
The best thing CISOs can do is reduce the potential blast radius of compromised identities, limit unnecessary application permissions, and gain more visibility into what’s happening in cloud environments. Likewise, organizations should routinely test their ability to detect and contain suspicious activity before it becomes a wider incident. A breach shouldn’t be the first time an organization realizes the potential of a compromised account. This is a question that should be known in advance by its security teams.
Share your exclusive thoughts to:
jeevika@thefoundermedia.in
About The Author
