Remove App Password in M365

Why Removing App Passwords Is Critical for Security Audits

You’re running a security audit. The checklist is long, the compliance requirements tight. Then you find them: app passwords scattered across old Slack threads, hardcoded in scripts, tucked in shared spreadsheets. They’re still active. Still working.

App passwords in Microsoft 365 are like backdoor keys left in the lock—accessible, unmonitored, and a direct bypass of multi-factor authentication. They’re a known weak point in any audit, a gap that violates the principle of least privilege and creates persistent risk.

This is how to remove app passwords in Microsoft 365 for security audit readiness. Not just to pass compliance checks, but to close real, active attack vectors before they’re exploited.

Key takeaways

App passwords bypass MFA and remain active long after the original device or app is decommissioned.
They’re frequently stored in unsecured locations like shared files or code repositories, increasing exposure.
Active app passwords during a security audit are a red flag for audit failures and indicate poor access management practices.

How to Identify Active App Passwords in Microsoft 365

You can find active app passwords in Microsoft 365 by signing in to the Admin Center as a Global Admin, going to Users > Active users > [select user] > Passwords, and reviewing the App passwords section. Each entry shows the app name, device, and last used date—use this to spot outdated, unused, or high-risk apps like old scripts or third-party tools. This step is critical for security audits and reducing credential exposure.

Step-by-step: Locate and review app passwords

Sign in to the Microsoft 365 Admin Center using a Global Admin account. Only Global Admins have access to user password management and app password logs. This ensures you’re working with the right permissions.
Navigate to Users > Active users. Select the specific user account you want to audit. You may need to filter by name or role if managing multiple users.
Go to the user’s Passwords section. This is a dedicated tab showing all password types the user has set up, including legacy app passwords. App passwords are often used by older apps or scripts that don’t support modern authentication.
Review each app password entry. The list includes the app name (e.g., "Outlook," "Custom Script"), the device name (if available), and the last used date. Apps without activity in the last 90 days should be flagged for deactivation.
Identify risk indicators. High-risk apps include old or unknown entries, especially those with no device name, or apps used repeatedly but no longer in active use. Scripts, unverified third-party integrations, or outdated automation tools fall into this category.

Why this matters for security posture

App passwords bypass modern authentication and multi-factor protection. An inactive app password left enabled can be exploited if credentials are leaked. The Microsoft Security Blog confirms that legacy authentication methods, including app passwords, are a top vector for account compromise.

The 5 steps described in “Step-by-step: Locate and review app passwords”, in order.

Regular audits help maintain a clean identity hygiene policy. For teams using third-party tools or automation, consider replacing app passwords with modern OAuth-based integrations where possible.

Remove old app passwords before they become your next breach point.

How to Remove an App Password from a Microsoft 365 User

You can remove an app password from a Microsoft 365 user by signing into the Microsoft 365 Admin Center, navigating to Users > Active users, selecting the user, opening the Passwords tab, finding the app password entry, and using the three-dot menu to delete it. The change takes effect immediately, invalidating the password for any app that was using it.

Step-by-step process to remove an app password

Go to the Microsoft 365 Admin Center and sign in with your admin credentials. Navigate to Users > Active users. Select the user account that has the app password you want to remove.
Open the Passwords tab. This section lists all passwords assigned to the user, including app passwords created for legacy authentication. App passwords are typically used by apps that don’t support modern authentication (like older email clients).
Locate the app password entry. It will appear under a heading labeled "App passwords" or similar. Each entry includes a brief description (e.g., "Outlook for Mac", "iPhone Email App") or the name of the device/app. Verify it matches the one you intend to delete.
Click the three-dot menu next to the password and choose Delete. Microsoft does not require a second confirmation prompt, so proceed carefully. Once deleted, the password is immediately invalidated.
Repeat for all unused or outdated passwords. Especially important during security audits: remove any app passwords that haven't been used in weeks or are tied to decommissioned devices. Microsoft does not track usage, so manual review is required.

Why this matters for security and compliance

App passwords bypass multi-factor authentication (MFA) and can remain active indefinitely. A 2023 report from Microsoft Security Intelligence noted that compromised app passwords were a common vector in account takeovers, often due to poor lifecycle management. Regularly auditing and removing unused app passwords reduces your attack surface. This is especially critical in regulated environments like healthcare or finance, where every credential must be tracked.

The 5 steps described in “Step-by-step process to remove an app password”, in order.

For larger organizations, manually reviewing every user’s app passwords is time-consuming. Tools like MailTester’s integrations with platforms like SendGrid and HubSpot help verify email infrastructure health, though they don’t handle app password management. Still, keeping your email system secure starts with removing unused or old access methods.

After deletion, users should re-authenticate with their primary account via MFA when reconnecting apps. This ensures only modern, secure methods persist. Microsoft no longer supports app password creation in new accounts by default—enforcing this process helps align with current best practices.

What Happens When You Remove an App Password

When you remove an app password in Microsoft 365, any app or script relying on it loses authentication access instantly. The user will see a login failure whenever the app tries to connect, and the app stops working until it’s updated. This is intentional: removing the password ends access, reducing risk if the password was compromised.

Immediate Impact on Applications and Scripts

Any application or script using the removed app password will fail to authenticate. You’ll see errors like “Authentication failed” or “Invalid credentials” — not just in logs, but in real user experiences if the app is part of a workflow. This disruption is immediate and doesn’t wait for a refresh interval.

Let’s say you use a third-party CRM to sync contacts from Outlook. If it’s using an app password and you remove it during a security audit, the sync fails right away. No warning, no gradual decline — it just stops. This highlights why you must coordinate the removal with app maintainers or admins.

Recovery Options and Modern Authentication

After removal, the app must either be reconfigured to use modern authentication or a new app password must be generated. Modern protocols like OAuth 2.0 are preferred because they don’t require storing static passwords. Instead, they use secure tokens, reducing long-term exposure risk.

According to Microsoft’s documentation, OAuth 2.0 is the standard for secure, scalable app access in cloud environments [Microsoft Learn]. Migrating to OAuth means you rely less on passwords, which are harder to manage and more prone to reuse or exposure.

If your app doesn’t support OAuth 2.0, generating a new app password is a short-term fix — but only if you store it securely and audit its use. App passwords should never be hardcoded or shared via email. Use a secrets manager or password vault, and log every generation and use.

For organizations managing large email lists or automated flows, consider using tools like MailTester to verify and monitor recipient addresses [bulk verification]. This reduces the chance of sending to outdated or compromised accounts, which might otherwise trigger security alerts or unnecessary app password use.

App Passwords Are a Known Security Risk — Here’s Why

App passwords in Microsoft 365 are a standing vulnerability: they stay active indefinitely, bypass MFA even when enforced, and are often used in scripts or tools with weak security controls. That means every app password you’ve created is a long-lived, unmonitored backdoor into an account—even if you’ve changed your main password or enabled MFA. Let’s break down why they should be removed during a security audit.

Why App Passwords Stay a Risk After Creation

App passwords are not tied to user sessions and never expire automatically—only you can delete them.
They bypass MFA requirements for specific apps, even if MFA is enforced for the rest of the user account.
When used with automation tools, they can be hardcoded into scripts or config files, increasing exposure if those files leak or are stored insecurely.
Unlike modern authentication methods, app passwords do not support session timeouts or revocation at the token level—once issued, they remain valid until manually removed.
They are commonly used in legacy workflows, scheduled tasks, or third-party integrations that lack modern security controls.

Poorly Managed Automation Amplifies the Risk

Many scripts or automation tools (e.g., backup utilities, data syncs) rely on app passwords instead of OAuth 2.0, which is preferred for secure access.
When app passwords are stored in plaintext or in version control systems like Git, they can be exposed in breaches or code reviews—no password change can mitigate this once leaked.
According to Microsoft’s own security guidance, apps should use modern authentication protocols like OAuth 2.0, not app passwords, for access to cloud services.
Organizations with many app passwords often lack visibility into how they’re being used, making it hard to detect misuse or unauthorized access.
You can’t audit their activity—no logs track the app password itself, only the user and IP, making post-breach analysis difficult.

For more context on secure email and identity practices, refer to the OWASP Top Ten guidelines, which highlight the risks of hard-coded credentials and improper authentication.

After removing app passwords, enforce modern authentication with MFA and use service accounts with least-privilege access. If you're managing user data or email lists, ensure each email is valid and secure—tools like MailTester’s bulk verification help confirm deliverability and identity integrity.

How to Prevent Future App Password Use

You can prevent future app password use in Microsoft 365 by enforcing MFA, restricting app password creation via Conditional Access, migrating legacy systems to OAuth 2.0 or Microsoft Graph API, and monitoring audit logs for suspicious activity. These steps reduce attack surface and align with Microsoft’s security recommendations for modern authentication.

Block App Passwords by Default

Enforce Multi-Factor Authentication (MFA) for all users. Once MFA is required, app passwords are no longer usable unless explicitly allowed by Conditional Access policies.
Use Azure AD Conditional Access to block app password creation entirely unless required for specific roles or apps. This limits access to only what’s necessary and follows the principle of least privilege.
Review and disable legacy authentication methods in Azure AD. Disabling "Legacy authentication" prevents app passwords from being issued at all, reducing risk from compromised or outdated clients.

Migrate to Modern, Secure Authentication

Migrate older apps, scripts, and integrations from basic auth to OAuth 2.0 or the Microsoft Graph API. These are the industry-standard methods for secure, token-based access and are more resilient than static credentials.
Use the Microsoft Identity Platform documentation to guide migration. The platform is built for scalability and security, and OAuth 2.0 is the foundation of modern web and cloud app authentication (see Microsoft’s official docs).
Test migrated apps in a controlled environment before rolling out to production. Ensure they handle token refresh, scopes, and consent correctly to avoid service disruption.
Enable audit logging in Microsoft Defender for Identity and monitor for "App password created" events. This lets you detect if app passwords are being created in violation of policy, even after restrictions are in place.
Set up alerts for anomalies like bulk app password creation, or access from unusual locations. Early detection helps prevent lateral movement after compromise.
Regularly audit which users or roles still require app passwords. If none do, disable the capability globally. For exceptions, document and justify them in your security policy.

For teams managing large email lists, use MailTester’s bulk verification to ensure senders are valid and reduce the risk of misdelivered messages from outdated or incorrect accounts.

Best Practice: Audit App Passwords Regularly

You should schedule quarterly reviews of all app passwords in Microsoft 365, automate discovery via PowerShell or SIEM tools, document each password’s purpose, owner, and expiry, and remove any that are unused or past their lifecycle. This reduces the risk of compromise from stale credentials and aligns with security best practices recommended by standards bodies like NIST.

Set a consistent review cadence

Run a full inventory of active app passwords every quarter using PowerShell or a SIEM platform like Microsoft Sentinel.
Use the Get-MgUserAppPasswordCredential command in Microsoft Graph PowerShell to list all app passwords assigned to user accounts.
Include this check in your formal security audit cycle to maintain compliance with frameworks like ISO 27001 or SOC 2.

Document and retire unused credentials

For each app password, record its intended use, the account it’s tied to, the owner, and the date it was created or last used.
Apply expiration policies: set a maximum lifespan of 90 days for app passwords, and disable or delete any that exceed it.
Remove any password that hasn’t been used in the past 6 months, especially those linked to legacy apps or third-party services no longer in use.
Verify that only required apps access Microsoft 365 via app passwords—prefer modern authentication protocols with OAuth when possible.

App passwords are a common attack vector; outdated or mismanaged ones often go unnoticed until breach detection. According to the Verizon Data Breach Investigations Report, weak or stolen credentials remain a top cause of data loss incidents. Regular auditing is not optional—it’s a necessary control.

“Credential hygiene isn’t a one-time task. It’s part of continuous security posture management.”

Use automation to scale this process. Custom PowerShell scripts can batch-export app password data and flag outliers. SIEM tools can alert on anomalies like bulk password creation or access from unusual locations.

For teams managing large email lists or integrating with multiple platforms, verify the validity and deliverability of email addresses used in authentication flows—invalid or disposable emails can undermine your audit’s reliability. MailTester’s bulk verification tool helps ensure your contact data remains clean and trustworthy: https://mailtester.com/email-list-verify.

The Cost of Not Removing Legacy App Passwords

Leaving legacy app passwords in Microsoft 365 unchecked is a security blind spot: attackers can exploit them long after the original user has left, especially when credentials are leaked in third-party breaches. These passwords often remain active indefinitely, bypassing modern authentication controls and acting as silent backdoors. Without routine cleanup, you risk compliance violations, delayed breach detection, and unnecessary exposure of sensitive data.

Exposure from Known Breaches

If a user’s app password is leaked in a data breach—say, from a third-party service or a compromised password manager—it can be reused to access Microsoft 365 without triggering alerts. Unlike regular passwords, app passwords aren’t tied to user sessions or MFA requirements, so they don’t get invalidated when MFA is enforced. This creates a persistent attack vector that can go unnoticed for months. According to the Verizon Data Breach Investigations Report, over 80% of breaches involve stolen or weak credentials, often leveraging legacy auth methods like app passwords.

Compliance and Incident Response Risks

Regulatory frameworks like GDPR, HIPAA, and ISO 27001 require organizations to minimize unnecessary access and continuously audit authentication methods. Retaining unused app passwords can trigger non-compliance findings during audits—especially when they violate the principle of least privilege. For example, a breach originating from a stale app password may take longer to detect than one using a standard login, delaying incident response times and potentially increasing penalties. The average time to identify a breach is 280 days, but silent entry points like dormant app passwords extend that window.

Even if you're not targeted directly, app passwords can become exploit vectors during supply chain compromises. An attacker who breaches a low-privilege app may use the app password to escalate access to corporate data. This is especially risky if the password was set up years ago and is no longer monitored. Regularly reviewing and removing obsolete app passwords is not just good practice—it's a necessary part of proactive identity security.

Tools like MailTester help ensure your email infrastructure remains trustworthy. By validating your email lists and testing inbox placement, you reduce the risk of compromise via phishing or bad actor campaigns that could exploit weak authentication. If your organization sends sensitive communications, verify your email domains and check deliverability status with real-time testing.

Bulk list verification helps you identify outdated or compromised email addresses—some of which may have been linked to legacy credentials. Use the real-time verification API to automate checks during onboarding or access reviews. If your security posture is tied to clean, accurate identity data, testing your email’s inbox placement can also signal whether your system is trusted by recipient systems.

App Password vs. Modern Auth: The Key Difference

You should remove app passwords in Microsoft 365 because they’re static credentials that never expire and bypass MFA—violating modern security standards. Modern authentication (like OAuth 2.0 and Microsoft Graph API) uses short-lived tokens, enforces MFA, and grants granular access. Only modern auth methods are supported in current Microsoft environments and comply with industry security requirements.

Why Static App Passwords Are a Security Risk

App passwords are long-lived, unchanging credentials. They’re designed for legacy apps that don’t support modern login flows, but that’s a trade-off: they’re easy to misuse, hard to track, and never expire. Even if you rotate them manually, they don’t require MFA, meaning a single stolen password can grant full access indefinitely.

That’s why Microsoft has deprecated app passwords in favor of modern authentication. Static credentials don’t adapt to real-time risks. If an app password is compromised, it’s a silent breach—no alert, no immediate revoke. In contrast, modern auth issues time-limited tokens tied to specific devices and user sessions. This significantly reduces the window of exposure.

How Modern Auth Meets Today’s Security Standards

Modern authentication uses OAuth 2.0 and the Microsoft Graph API to authenticate apps with short-lived access tokens. These tokens expire within hours or minutes and require MFA enforcement. Even if stolen, they’re useless outside their short lifespan.

Modern auth also enables granular permission scopes. Instead of granting full mailbox access, an app can request only read-only calendar data. This follows the principle of least privilege—an industry-standard security practice backed by NIST and the OWASP Top Ten.

Today’s security landscape demands more than passwords. As Microsoft continues to phase out legacy auth methods, only modern authentication aligns with current best practices. For a deeper look at how authentication impacts email security, explore our inbox placement tests: inbox placement testing shows how authentication flaws affect deliverability.

When managing user access—especially for audits—you must eliminate long-lived credentials like app passwords. That’s not just good policy; it’s required to meet compliance standards and reduce your attack surface.

How MailTester Helps Clean Email Lists During Security Audits

You can’t directly remove app passwords in Microsoft 365 using MailTester, but you can strengthen your security posture during audits by cleaning outdated or risky email addresses from your systems. By verifying every email in your user lists, automation workflows, or contact databases, you reduce the chance of relying on inactive accounts, role-based addresses, or disposable domains that may be linked to obsolete or high-risk access patterns.

Identifying High-Risk Email Types

Many app passwords are created for long-standing or inactive accounts. If your list includes outdated or role-based emails like [email protected] or [email protected], these can signal poor hygiene. MailTester’s bulk verification flags these addresses early, showing you exactly which ones are valid, catch-all, or at risk—common indicators of unused or poorly managed accounts.

Disposable domains and temporary email services are frequent red flags. While not all such addresses are malicious, they often appear in lists used for testing or automation, where they might inadvertently trigger app password creation if users attempt to access systems. MailTester detects these with high precision, helping you remove them before they pose a security or compliance risk.

Supporting System Accuracy and Reducing Risk

When your email lists are accurate, you're less likely to assign access to accounts that no longer exist. Outdated records encourage users to create app passwords for legacy systems instead of using modern, secure methods. Cleaner lists mean fewer users resort to workarounds, reducing both attack surface and audit findings.

Using MailTester’s real-time verification API or bulk list tool, teams can schedule regular checks during audit cycles. This ensures that any automation, marketing, or onboarding process relies only on active, legitimate addresses. You can integrate MailTester directly with platforms like HubSpot, SendGrid, and Klaviyo to automate cleanup and keep records compliant and current.

Avoiding the use of role-based or disposable emails in production systems isn’t just about deliverability—it's about security hygiene. According to the CISA guidance on securing external access, weak account hygiene is a common factor in identity-based breaches.

With 98.9% accuracy and an AI assistant to help interpret results, MailTester gives you the confidence to act. Try a free batch of 100 verifications at https://mailtester.com/email-list-verify. Credits never expire, so you can clean lists consistently, not just when an audit is imminent.

Final Step: Document Your Audit and Remove Risky Access

After removing app passwords, maintain a clear audit trail. Record each password's creation date, owner, purpose, and removal timestamp. This log is essential for compliance, incident response, and future security reviews.

Update Access Controls and Notify Teams

Remove obsolete entries from access control lists. Document any required app passwords that remain—justify each with a formal approval ticket.
Notify team leads and IT staff of the changes. This prevents disruption to automated workflows that rely on legacy authentication.

Strengthen Policies and Training

Update your organization's security policy to reflect the risks of app passwords. Include clear guidelines on when and how to use them, and emphasize that third-party apps should use modern authentication (OAuth) instead.

Train staff on these changes. Reinforce that shared app passwords increase breach risk and violate least-privilege principles.

Sources

At regional mailbox providers, 15.5% of email goes missing without a trace versus only 2.8% filtered to spam — the inverse of the pattern at Gmail, Microsoft, Yahoo, and Apple. — Validity 2025 Email Deliverability Benchmark Report (2025)
Benchmark testing of 15 major email service providers found about 10.5% of legitimate emails land in the spam folder and a further 6.4% go undelivered. — EmailTooltester deliverability benchmark (via WarmForge) (2026)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can I remove my own app password in Microsoft 365?

No — only a Global Admin can remove app passwords for other users. You can delete your own app password if you're the owner, but it requires logging in with a supported method.

What if an app stops working after removing an app password?

The app must be updated to use Microsoft’s modern authentication (OAuth 2.0) or a new app password must be generated. Use the new password only after confirming it’s necessary and securely stored.

Are app passwords still allowed in Microsoft 365?

Yes, but only for legacy apps that do not support OAuth 2.0. They should be used sparingly and removed after the app is updated.

Can app passwords be used with MFA?

No — app passwords bypass MFA. Even if a user has MFA enabled, app passwords do not require it to work.

How often should I audit app passwords?

At least once every quarter, or whenever changes occur in user access, IT policy, or system integrations.

What’s the alternative to app passwords?

Use OAuth 2.0 or Microsoft Graph API for app authentication. These methods support MFA, token expiry, and scoped permissions.

Are app passwords stored securely by Microsoft?

Microsoft stores them encrypted, but they are not automatically rotated, so they remain a persistent risk if not manually removed.

How do I know if an app password is still in use?

Check the date of last use in the Microsoft 365 Admin Center. If unused for 90+ days, it’s likely safe to remove.

Can role-based emails have app passwords?

Yes — role accounts like admin@ or sales@ can have app passwords. These are common attack targets and should be audited carefully.

Why are app passwords a problem for security audits?

They represent a single point of failure with no MFA and no expiration. They are frequently overlooked in audits, creating compliance gaps.