Table of Contents
Introduction
In the first two posts of this Zero Trust series, we established that identity is the new perimeter and devices are the frontline of defence. By verifying every user and ensuring only healthy, compliant endpoints connect to your environment, you lay the foundation for a robust security posture.
However, the story doesn’t end there. The third pillar – Applications. This is where your organisation’s data resides and business processes run. Applications, whether cloud-based (like Microsoft 365), on-premises, or custom-built, are increasingly targeted by attackers seeking to exploit vulnerabilities, misconfigurations, or risky integrations.
Securing applications is essential for a true Zero Trust approach. It’s not enough to trust users and devices; every app must be explicitly validated, monitored, and controlled. In the Microsoft 365 ecosystem, this means leveraging technologies such as:
- Microsoft Defender for Cloud Apps for app discovery, monitoring, and threat protection
- Microsoft Entra ID for Conditional Access, app consent controls, and authentication policies
- Sensitivity labels and Data Loss Prevention (DLP) to protect data within and across apps like SharePoint, Teams, and OneDrive
- Microsoft Sentinel for centralised monitoring and automated response
By applying Zero Trust principles to applications, you ensure that only the right people, on trusted devices, under the right conditions, can access your organisation’s most valuable assets. This approach helps prevent data breaches, unauthorised access, and the spread of shadow IT, while enabling secure collaboration and productivity.
Application Threat Landscape
As organisations increasingly rely on cloud apps like Microsoft 365, the threat landscape has evolved. Attackers now focus on exploiting applications as entry points to sensitive data and business processes. Key threats include:
- OAuth Consent Phishing: Attackers trick users into granting permissions to malicious apps, enabling access to emails, files, and contacts without further interaction.
- Shadow IT: Unauthorised or unsanctioned apps used by employees can bypass security controls, leading to data leakage and compliance risks.
- Vulnerable Integrations: Poorly secured third-party integrations or custom apps can introduce vulnerabilities, allowing attackers to move laterally or exfiltrate data.
- Misconfiguration: Default or overly permissive settings in apps like SharePoint, Teams, or OneDrive can expose sensitive information to unauthorised users.
- Malicious App Behaviour: Apps with excessive permissions may access, modify, or export data beyond their intended scope.
- Legacy Authentication: Older protocols (e.g., IMAP, POP, SMTP Basic Auth) lack modern security controls and are frequently targeted for brute-force or credential stuffing attacks.
- Data Exfiltration: Attackers use compromised apps or accounts to export sensitive data, often undetected by traditional security tools.
Microsoft 365 provides native tools to address these threats, including Defender for Cloud Apps for app discovery and monitoring, Entra ID for consent management and Conditional Access, and Sentinel for centralised threat detection and response.
Challenges
Implementing Zero Trust for applications is not without its obstacles. Organisations face a range of technical and operational challenges, including:
- Visibility and Discovery: Identifying all applications in use, especially unsanctioned or shadow IT, is difficult, as users often adopt new tools without IT oversight.
- Managing Permissions: Controlling who can grant app permissions, and ensuring apps only have the minimum required access, is complex in large environments.
- Balancing Security and Productivity: Overly restrictive policies can hinder collaboration and user experience, while permissive settings increase risk.
- Legacy Systems and Protocols: Older applications and authentication methods may not support modern security controls, making them harder to secure.
- Rapid Change and Integration: The pace of cloud adoption and third-party integrations means new apps and risks are constantly emerging.
- User Awareness: Employees may not recognise the risks of granting permissions to apps or using unsanctioned tools, increasing the likelihood of accidental data exposure.
- Monitoring and Response: Detecting and responding to suspicious app activity requires integrated tools and processes, which can be challenging to implement and maintain.
Addressing these challenges requires a combination of technology, policy, and user education leveraging Microsoft 365’s native security features and fostering a culture of shared responsibility.
Reasons
Let’s be honest applications are where the magic (and the mayhem) happens in modern organisations. It’s no longer just about locking down your network or making sure everyone’s laptop is up to scratch. The real action is in the apps your people use every day.
Think about it: your team is collaborating in Teams, sharing sensitive docs in SharePoint, firing off emails in Outlook, and crunching numbers in Power BI. These aren’t just tools, they’re the beating heart of your business. And if an attacker gets into one of these apps, they’re not just poking around, they’re rifling through your company’s crown jewels.
Why do we need to take application security seriously?
- Because attackers are getting smarter. They know that if they can trick someone into granting access to a dodgy app, or exploit a misconfigured integration, they can bypass all your shiny new identity and device controls.
- Because shadow IT is everywhere. Let’s face it, people will always find a way to use the app that makes their job easier, even if it’s not officially approved. That’s great for productivity, but a nightmare for security.
- Because collaboration is a double-edged sword. Microsoft 365 makes it ridiculously easy to share and work together, but without the right controls, sensitive data can end up in places it shouldn’t, sometimes with just a single click.
- Because compliance isn’t optional. Whether it’s GDPR, the Data Protection Act, NHS DSPT (Data Security and Protection Toolkit) for healthcare, or sector-specific standards like ISO 27001, every organisation, public or private needs to know exactly where its data is, who can access it, and how it’s protected. For the NHS and other healthcare providers, safeguarding patient information isn’t just best practice, it’s a legal and ethical requirement. In the public sector, transparency and accountability are paramount, while private sector firms face increasing scrutiny from regulators and customers alike. Ultimately, keeping your board happy means demonstrating robust controls and clear evidence that your apps and data are secure, compliant, and well-managed.
In short, securing applications isn’t just a technical box-ticking exercise it’s about protecting the lifeblood of your organisation, enabling your people to work safely, and staying one step ahead of the bad guys. Zero Trust for apps means you’re not just hoping for the best you’re actively making sure only the right people, on the right devices, under the right conditions, can get to what matters most.
Pre-requisites
Before you can secure applications as part of a Zero Trust strategy, you need a solid foundation. Here’s what to get right first:
- Know your app landscape. You can’t protect what you don’t know exists. Fire up Microsoft Defender for Cloud Apps and run a discovery scan. You’ll be surprised, there’s always that one team using a random file-sharing app because “it’s easier than SharePoint.” Shadow IT isn’t just a buzzword; it’s real, and it’s risky.
- Get identity and device controls nailed. If you’re still relying on passwords and unmanaged laptops, stop here. Zero Trust for apps only works if you’ve got phishing-resistant MFA and device compliance in place with Intune and Defender for Endpoint. Otherwise, you’re building on sand.
- Centralise app management. Integrate apps with Microsoft Entra ID for single sign-on and Conditional Access. Why? Because chasing down separate logins and permissions is like herding cats, and er all know that cats don’t like being herded.
- Categorise Apps:
Create clear categories such as Approved, Under Review, and Blocked. Publish these lists internally so users know what’s safe.
Tip: Use MCAS governance actions to block risky apps automatically and integrate with Conditional Access for enforcement. - Define your data sensitivity. Not all data is equal. Use sensitivity labels and DLP policies in Microsoft 365 to figure out what’s crown jewels and what’s garden-variety. That way, you know which apps need Fort Knox-level security.
- Get stakeholder buy-in. This isn’t just an IT project. If finance suddenly loses access to their reporting tool because of a new policy, you’ll hear about it, loudly. Bring them in early, explain the “why,” and you’ll turn resistance into support.
- Stay current. Patch your apps and integrations. Outdated software is basically an open invitation for attackers. Don’t let your environment become their playground.
- Assess Risk and Compliance:
Check whether apps meet standards like GDPR or ISO 27001.
Why This Matters
Skipping these steps is like installing a high-tech alarm system on a house with no front door. Real-world example? I’ve seen organisations enforce Conditional Access without first mapping their app usage. Result: users locked out of critical tools, productivity nosedived, and IT became the villain overnight. A quick discovery scan with Defender for Cloud Apps would have avoided that drama.
Bottom line: Nail these pre-requisites and you’ll set yourself up for success. Skip them, and you’ll spend more time firefighting than securing.
Integrate Apps with Microsoft Entra ID
Centralising identity is critical for Zero Trust. By bringing all applications under a single identity plane, you gain visibility, enforce consistent security policies, and reduce attack surfaces.
Enable Single Sign-On (SSO)
What to do: Integrate all approved apps, Microsoft 365, SaaS, and custom line-of-business apps with Entra ID for unified authentication.
Why it matters:
- Without SSO, enforcing MFA and Conditional Access is fragmented and inconsistent.
- Centralised sign-ins allow you to monitor risk signals, apply adaptive policies, and simplify user experience.
Best Practice:
- Use SAML or OIDC for standards-based integration.
- Validate app configurations regularly to avoid misconfigurations that could bypass security controls.
- For high-risk apps (finance, HR), enforce phishing-resistant MFA (FIDO2, Windows Hello for Business).
Turn on Admin Consent Workflow
What to do: Enable the Admin Consent Workflow in Entra ID to prevent users from granting permissions to third-party apps without review.
Why it matters:
- OAuth consent phishing is a growing attack vector, malicious apps can gain persistent access to email, files, and contacts without triggering MFA.
Best Practice:
- Restrict consent to security-approved admins only.
- Review pending requests regularly and revoke unnecessary or suspicious grants.
- Use Conditional Access + App Consent Policies to block risky apps and enforce least privilege.
Additional Recommendations
Keep an Eye on OAuth Grants
Attackers love excessive permissions, don’t make it easy for them.
- Head to the Enterprise Applications blade in Microsoft Entra ID and audit permissions regularly.
- Look out for apps with high-risk permissions like
Mail.ReadWriteorFiles.ReadWrite.Allrevoke anything unnecessary. - Set up Access Reviews for app permissions, especially for sensitive roles or high-privilege apps.
- Automate alerts for new app consent grants using Microsoft Sentinel or Entra ID governance features. If something looks dodgy, you’ll know about it before it becomes a breach.
Conditional Access: Your Best Friend
Lock down app access without killing productivity.
- Require phishing-resistant MFA for all apps, start with finance, HR, and privileged apps.
- Enforce device compliance checks so only managed or compliant devices get through.
- Block legacy authentication protocols (POP, IMAP, SMTP Basic Auth) they’re basically an open door for attackers.
- Use session controls to restrict risky actions like downloads, copy/paste, and printing from unmanaged devices.
Important Note:
- All native Microsoft apps (Exchange Online, SharePoint, Teams, etc.) support modern authentication, so blocking Basic Auth for these is safe and recommended.
- However, some third-party or legacy apps may not yet support modern auth. For these:
- Create a separate Conditional Access policy that allows Basic Auth only for specific apps or service accounts.
- Apply additional controls (e.g., IP restrictions, MFA where possible, or service account isolation).
- Monitor usage and plan migration to modern auth as soon as feasible.
Best Practice:
- Audit sign-in logs to identify apps still using Basic Auth.
- Communicate timelines for deprecation and provide alternatives to business units.
Defender for Cloud Apps: Go Beyond Discovery
You’ve already used it to find shadow IT, now make it work harder.
- Enable Cloud App Discovery to keep tabs on unsanctioned apps.
- Apply real-time session controls like download restrictions, watermarking, and blocking risky activities.
- Configure risk-based policies to catch anomalies—mass downloads, unusual sharing, or suspicious OAuth activity.
- Use App Governance for deeper visibility into OAuth apps and their behaviour. If an app starts acting shady, you’ll know.
Educate Your Users (Seriously, It Works)
Technology can only do so much, people need to play their part.
- Run awareness campaigns explaining why app consent matters and the risks of shadow IT.
- Give clear guidance on how to request new apps through approved channels.
- Share real-world attack examples (like OAuth consent phishing) to make the risks tangible.
- Encourage reporting of suspicious apps or unexpected consent prompts. A quick report can stop a big problem.
Protect Data Inside Apps
Securing access isn’t enough, you must protect the data within the applications themselves. While the next pillar in this series will focus entirely on Data (classification, encryption, lifecycle management), here are essential app-level protections you should implement now:
- Apply Sensitivity Labels and DLP Policies:
Use Microsoft Purview to classify and protect sensitive data inside apps like SharePoint, Teams, and OneDrive. This ensures that even if access controls fail, data remains governed and protected. - Restrict External Sharing:
Configure SharePoint and Teams to allow sharing only with approved domains.
Example: Block personal email domains like Gmail or Yahoo to prevent accidental leaks.
Why This Matters:
Applications are the gateway to your organisation’s most valuable data. By applying these controls at the app level, you reduce the risk of accidental exposure and strengthen compliance. For a deeper dive into data-centric security including encryption, auto-labelling and insider risk management, stay tuned for Pillar 4: Data.
Sample Conditional Access Policies for Applications
As we now know, Conditional Access is the engine of Zero Trust—where strategy becomes reality. With each pillar, Conditional Access adapts to new risks and requirements. In the context of applications, it’s not just about who can sign in, but how, where, and what they can do once inside. By layering session controls and app governance, you ensure your most critical business apps remain secure, no matter how or where they’re accessed.
Policy 1: Require MFA for All App Access
This policy is a direct continuation of what we established in Pillar 1 (Identity): requiring phishing-resistant MFA is the foundation of Zero Trust. Just as we protect user identities with strong authentication, we extend the same guardrail to every application—ensuring that even if credentials are compromised, attackers can’t access your business-critical apps.
- Scope: All cloud applications.
- Action: Enforce phishing-resistant MFA (FIDO2, Windows Hello for Business) for every sign-in.
- Why: Prevents attackers from accessing apps, even if credentials are compromised.
- Pro Tip: Use Authentication Strengths in Entra ID to require strong MFA for sensitive apps (e.g., finance, HR).
Policy 2: Block Legacy Authentication
Legacy protocols are like rusty padlocks, they look secure but snap under pressure.
- Scope: All apps using POP, IMAP, SMTP Basic Auth.
- Action: Disable legacy protocols that bypass modern security controls.
- Why: Eliminates outdated protocols frequently targeted for brute-force attacks.
- Important Note:
- All native Microsoft apps support modern authentication—safe to block Basic Auth.
- For third-party or legacy apps still requiring Basic Auth:
- Create a separate policy allowing Basic Auth only for those apps or service accounts.
- Apply extra safeguards (IP restrictions, MFA where possible, and monitoring).
- Audit sign-in logs and plan migration to modern authentication ASAP.
Policy 3: Restrict Downloads from Unmanaged Devices
Think of unmanaged devices as strangers at your dinner table—you don’t want them walking off with the silverware.
- Scope: SharePoint, OneDrive, Teams.
- Action: Use session controls to block downloads, clipboard, and print actions from unmanaged devices.
- Why: Prevents sensitive data from being saved on endpoints outside your control.
- Example: Allow web-only access for BYOD laptops but block file downloads.
Policy 4: Limit App Permissions
OAuth consent phishing is the digital equivalent of handing your house keys to a stranger because they asked nicely.
- Scope: All apps integrated with Entra ID.
- Action: Enable Admin Consent Workflow and restrict who can grant OAuth permissions.
- Why: Prevents risky third-party integrations and OAuth consent phishing.
- Best Practice: Combine with App Governance in Defender for Cloud Apps for deeper visibility.
Monitor and Respond: Automate Everything You Can
Manual checks are fine, until you’re drowning in them.
- Use Conditional Access templates for app protection to speed up deployment.
- Automate revocation of inactive apps with PowerShell or Graph API scripts.
- Integrate Sentinel playbooks for automated incident response when risky app behaviour is detected.
Pro Tip: Start with the apps that matter most—finance, HR, and anything with privileged access. Lock those down first, then expand. Trying to secure every app on day one is a recipe for chaos (and angry emails).
Common Pitfalls and How to Avoid Them
- Ignoring Shadow IT: Run regular discovery scans with Defender for Cloud Apps.
- Overly Permissive OAuth Grants: Enforce Admin Consent Workflow.
- Blocking Productivity: Pilot policies before full rollout.
- Neglecting Monitoring: Integrate Sentinel for continuous visibility.
Resources and Further Reading
- https://learn.microsoft.com/en-us/cloud-app-security/
- https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/
- https://learn.microsoft.com/en-us/azure/sentinel/
- https://learn.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels
Conclusion
Applications are where your organisation’s crown jewels live, data, processes, and collaboration. Zero Trust for apps means verifying every access request, enforcing least privilege, and continuously monitoring for threats. By combining Entra ID, Defender for Cloud Apps, and Sentinel, you create a dynamic security posture that protects your apps without slowing down your business.
Coming up next: Pillar 4 – Data
Securing application access is only half the battle. The real value—and risk—lies in the data within those apps. Even with airtight app controls, sensitive information can still be exposed, mishandled, or exfiltrated if not properly protected. That’s why the next pillar in this series focuses on Data: classification, encryption, lifecycle management, and insider risk. In Pillar 4, we’ll explore how to safeguard your organisation’s information—wherever it lives, moves, or is shared.
