Find unused Azure resources with Azure Resource Graph, then confirm ownership, dependencies and activity before deleting them. Resource Graph identifies unattached infrastructure across subscriptions, but unattached does not mean unnecessary. Use Azure Monitor to assess activity and Azure Cost Management to establish which candidates are generating charges. Start with an inventory rather than a deletion script. Separate resources that can be removed permanently from workloads that need resizing, scheduled shutdown or continued retention. Key takeaways for Azure resource cleanup Treat Resource Graph results as review candidates, not approval to delete. Distinguish allocated compute, retained storage and contractual commitments when calculating savings. Record owner approval, recovery requirements and the exact resource IDs before removal. Automate discovery first, then introduce shutdown schedules for explicitly approved workloads. Find unused Azure resources with Resource Graph Azure Resource Graph queries Azure resource inventory at scale across subscriptions using Kusto Query Language (KQL). In the Azure portal, open Resource Graph Explorer, select the intended subscriptions and run each query below separately. Start with Reader access at the required scope. Results only cover resources the querying identity can access, so a successful query does not prove the entire estate was examined. The Resources table contains configuration records, not historical CPU or transaction metrics. Microsoft’s advanced Resource Graph examples demonstrate how queries can combine resource properties, tags and relationships. Export results with resource IDs, subscription IDs and resource groups. Add ownership and cost information before making changes. Identify unattached disks and public IP addresses Find managed disks without an attached VM This query identifies disks where managedBy is empty or diskState is Unattached: Query matches may be orphaned resources, but they are candidates for review, not automatic deletions. An unattached managed disk can still incur storage charges. However, it may contain retained application data, support a recovery workflow or have been detached temporarily during maintenance. Review shared-disk references, Azure Site Recovery dependencies and backup requirements before deletion. The open-source Azure orphan-resource query collection highlights Site Recovery exclusions, which matter when adapting discovery queries. Record the data owner’s decision. Do not create a snapshot automatically unless its retention purpose and additional cost are justified. Find unassociated public IP addresses Public IPs without an IP configuration or NAT gateway association are candidates for review: Inspect service-managed associations, DNS records, partner allowlists and planned deployments. Deleting an address can release it; recreating the resource does not guarantee the same address. Review orphaned networking and availability resources Find network security groups without attachments This query selects network security groups (NSGs) with no network interfaces or subnets attached: An unattached NSG may contain approved rules for a forthcoming deployment. Compare it with infrastructure-as-code definitions and the network design before removing it. Find detached network interfaces Exclude interfaces associated with either a VM or a private endpoint: Review associated public IPs, DNS settings and application configuration. An unused network interface does not establish that its connected resources can all be deleted. Find empty availability sets Availability sets with no VM members have a virtualMachines array length of 0. This query also handles an omitted array: Confirm that no virtual machines use the set and that deployment templates no longer reference it. Removing empty availability sets, ordinary network interfaces and NSGs mainly simplifies management; these resources do not normally carry standalone charges. Prioritise chargeable disks, public IPs and running compute when the immediate objective is reducing expenditure. Use monitoring to distinguish idle resources from required ones Assess VM activity beyond CPU A low CPU utilization reading is a review signal, not proof that a VM is redundant. File servers, authentication services and disaster recovery systems can remain necessary despite limited processing activity. A threshold such as CPU below 5% over 30 days can produce a shortlist. Review network traffic, disk activity, application schedules and recovery responsibilities alongside it. Include month-end processing and other infrequent business tasks. Azure Advisor can identify optimisation opportunities, whilst Azure Cost Management shows the expenditure attached to each candidate. Neither replaces the workload owner’s decision. Assess storage transactions and data purpose For storage accounts, review Azure Monitor transaction metrics across the Blob, File, Queue and Table services actually in use. Use Total aggregation over a period that includes relevant operating cycles. Inspect object or file modification dates separately. Reads do not necessarily update modification timestamps, and account configuration dates do not establish when stored data was last accessed. Use configured Azure Monitor Logs for additional diagnostic evidence. Missing logs do not prove inactivity. Archive data, recovery copies and retained business records can legitimately show little activity. Review purpose and retention before removal; our guidance on Azure Storage security also covers ownership, access and recovery controls. Confirm ownership and dependencies before removal Owner approval should identify the business purpose, affected application, retention requirements and recovery route. A tag naming a department is insufficient if nobody accepts responsibility for the decision. Use a documented removal sequence: Record the exact resource ID, owner, current cost and reason for removal. Review dependencies in application configuration, deployment templates, DNS, network rules, identities, backup and recovery systems. Preserve required records and agree a recovery method, observation period and change window. Obtain approval, remove the selected resource and test the affected services. Review remaining dependencies and charges, then update the asset register and next review date. Where a reversible stop or configuration change is available, use it before permanent deletion. Do not simulate retirement by weakening authentication or exposing data. In the portal, open the approved resource, select Delete and review the confirmation carefully. Avoid deleting an entire resource group unless every contained resource has been assessed. Update infrastructure-as-code definitions so the next deployment does not recreate retired resources. Separate stopping compute from ending all charges A VM stopped inside its operating system can remain allocated and billed. Deallocation releases its compute allocation; the required status is Stopped (Deallocated). For command-line operations, the Azure CLI reference distinguishes az vm stop from az vm deallocate. The former does not release the compute allocation. The remaining billing position depends
Microsoft 365 SMTP AUTH: find and secure legacy senders
Microsoft 365 SMTP AUTH connections using Basic authentication remain available through December 2026, subject to existing tenant policies. At the end of December, Microsoft will disable Basic authentication by default for existing tenants, although administrators can re-enable it temporarily. Identify password-based senders now and plan their replacement. The Microsoft SMTP AUTH change concerns the authentication method, not the removal of SMTP itself. Websites, scanners and scripts may need changes even when Outlook works normally. Start with the timetable, then establish which connections your organisation uses. What changes in December 2026? Microsoft’s updated SMTP AUTH deprecation timeline separates the default switch-off from permanent removal. These are different events. Date Change Practical consequence 16 September 2024 Basic authentication ended for personal Outlook.com, Hotmail.com and Live.com accounts. These accounts require Modern authentication. Through December 2026 Exchange Online SMTP AUTH Basic authentication behaviour remains unchanged. Existing policies can still block it. End of December 2026 Basic authentication is disabled by default for existing tenants. Administrators can re-enable it temporarily. After December 2026 New tenants have Basic authentication unavailable by default. OAuth is the supported authentication method. Second half of 2027 Microsoft will announce the final removal date. This is an announcement window, not the final cutoff. The personal-account deadline was a separate change. Microsoft’s consumer authentication guidance does not mean that every Microsoft 365 business sender lost access in 2024. Key takeaways Identify authenticating accounts and their underlying devices, applications and owners. Disable unused SMTP AUTH access, but account for mailbox overrides and separate security policies. Replace Basic authentication with OAuth, Microsoft Graph or a suitable relay, then test authentication and delivery separately. Find affected senders and effective settings Use the SMTP AUTH clients report Open the Exchange admin centre, select Reports, then Mail flow and the SMTP AUTH clients report. Microsoft’s report documentation describes the default 7-day window. Review sending accounts, message counts and Basic or Modern authentication. Map each account to its actual senders. Several printers and scanners, along with applications, may share one mailbox, so an account entry doesn’t provide a complete device inventory. Include CRM platforms, payroll notifications, website forms and scheduled scripts. Record the owner, authentication method, From address and business purpose. Extend the review beyond 7 days to capture monthly reports and occasional notifications. Establish which settings apply Review SmtpClientAuthenticationDisabled using Get-TransportConfig and Get-CASMailbox. At mailbox level, True disables SMTP AUTH, False enables it, and an unset value inherits the organisation setting. Turn off SMTP AUTH for the whole organisation with Set-TransportConfig -SmtpClientAuthenticationDisabled $true; use Set-CASMailbox to disable it for an individual mailbox. A mailbox-level enablement can override organisation-wide SMTP AUTH disablement. However, authentication policies or Security Defaults can still prevent the connection. Microsoft 365 administrators can also manage the mailbox control in the Exchange admin center under Users, Active users, Mail, Manage email apps, Authenticated SMTP. Distinguish enabling the protocol from permitting Basic authentication. Our Microsoft 365 and cloud support can place these exceptions alongside account ownership and wider organisation administration. Choose a replacement that fits the sender Basic authentication submits a reusable username and password. It cannot enforce multi-factor authentication during that exchange and remains exposed to password spraying and brute-force attacks. OAuth tokens carry permissions and expire. You can withdraw authorisations, but an issued access token may remain valid until expiry. Unattended applications also need credential protection; OAuth doesn’t make them equivalent to an MFA-protected user session. Choose the route according to application support and recipient requirements. Sending route Suitable use Main constraint SMTP with OAuth Compatible devices and existing SMTP applications Client must support OAuth and token renewal. Microsoft Graph Applications that can send over HTTPS Requires API integration and appropriate permissions. Transactional SMTP relay Password-based devices and transactional applications Separate credentials, charges and domain authentication. A relay can remove the dependency on Microsoft mailbox passwords without removing password-based authentication entirely. Its credentials still need restricted access and rotation. Move compatible SMTP clients to OAuth 2.0 Use supported integrations first Applications offering Sign in with Microsoft normally handle their own app registration. Easy WP SMTP’s Microsoft 365 / Outlook mailer with One-Click Setup similarly avoids a custom Entra registration. For scan-to-email, Ricoh, Canon, Kyocera, HP, Toshiba and Lexmark offer OAuth support on supported models, often through firmware updates. Manufacturer support does not establish that every older device can be upgraded. Use smtp.office365.com, port 587, STARTTLS and OAuth authentication. Changing the host or selecting TLS does not convert a stored-password connection to OAuth. Register a custom application where necessary For applications your organisation develops or controls, follow Microsoft’s SMTP OAuth implementation guidance. Register the application in Microsoft Entra ID and configure the redirect URI required by its authentication flow. For delegated access, add Exchange Online’s SMTP.Send permission and request the https://outlook.office.com/SMTP.Send scope. Request offline_access when refresh tokens are needed. Obtain consent and tokens through the supported flow, then authenticate SMTP using SASL XOAUTH2 rather than a mailbox password. For unattended app-only access, use SMTP.SendAsApp, administrator consent and the required Exchange service-principal and mailbox authorisation. Adding the Entra permission alone is insufficient. Protect application credentials and document renewal ownership. Review consent carefully; our guidance on Microsoft device-code phishing explains why a legitimate Microsoft sign-in page does not establish that an authorisation request is safe. Use Microsoft Graph or a transactional relay Send through Microsoft Graph over HTTPS The Microsoft Graph API sends mail through HTTPS rather than SMTP. Applications use POST /me/sendMail for delegated access or POST /users/{id}/sendMail for the relevant user, with the Mail.Send permission. Microsoft’s sendMail API documentation distinguishes request acceptance from completed delivery. A successful API response isn’t proof that a recipient received the message. Restrict application access to the required mailboxes. Graph is also useful where a web host blocks port 587. API-based WordPress mailers can send over HTTPS, although they must support the selected provider and authentication flow. Configure a transactional SMTP service A transactional email service using SMTP relay is often practical when an application supports SMTP credentials but can’t implement OAuth. For SendLayer, set the SMTP server to
How to use Microsoft 365 message trace for missing emails
Microsoft 365 message trace helps you troubleshoot mail delivery by showing whether Exchange Online received, delivered, delayed or blocked an email. Open Mail flow > Message trace in the Exchange admin centre, search by sender, recipient and time, then inspect the events behind the result. A Delivered status doesn’t establish that the recipient saw the message or that it remains in their Inbox. Start with the delivery record, then investigate the mailbox, filtering or external system indicated by the evidence. Key takeaways Search the past 90 days, using a maximum 10-day window for each query. Start with an online Summary report; request downloadable reports when routing or client IP details are needed. Read message events before changing rules, releasing quarantined messages or adding exceptions. Treat message trace, mailbox activity and authentication records as separate evidence sources. They answer different questions. Establish access and collect the message details Message trace requires administrative access. Microsoft lists Global Administrator, Exchange Administrator or membership of the Organization Management role group for the Exchange admin center experience. Avoid granting Global Administrator solely for email troubleshooting. View-Only Recipients supports viewing downloaded reports in the classic workflow, but should not be treated as general access to the new trace experience. Collect the sender address, recipient address, approximate sending time, time zone and subject before searching. Obtain the full Message ID from the message headers where available, particularly when several messages have similar subjects. For a rejected message, retain the non-delivery report as well. Its diagnostic information may identify the rejecting system before a wider investigation is needed. Message trace records mail flow, not sign-in activity or every subsequent mailbox action. A trace result can explain delivery without establishing who later moved or deleted the email. Run a Microsoft 365 message trace Start with the narrowest reliable search: the exact sender and recipient, plus a short time window. This reduces unrelated results without relying on a subject that may have changed during a conversation. Open the trace and set its scope Open the Exchange admin center using an authorised administrator account. Select Mail flow, then Message trace, and choose Start a trace. Enter the sender or recipient, select the time range and choose a Summary report. Run the search, select the matching result and open its details. Check the selected time zone before interpreting timestamps. A report based on the wrong time zone can exclude the message even when the calendar date appears correct. Use *@domain.com in Senders or Recipients to search all addresses within a domain. Narrow the date range when searching a busy supplier or customer domain. Add detailed filters without hiding the evidence Optional filters include Subject, Message ID, Client IP address and Delivery Status. Use a subject filter when the wording is distinctive; options include starts with, ends with and contains. Use contains when a reply prefix or additional wording may have changed the subject. Use the Message ID when the investigation needs to distinguish one message from repeated submissions. Leave Delivery Status unrestricted initially. Searching only for Failed messages will miss an email that was quarantined, deferred or successfully delivered elsewhere. If nothing appears, remove optional filters and widen the time window before concluding that Exchange Online never received it. Choose the report that answers the question Summary reports are available almost immediately online and cover up to 10 days per query. Historical data remains searchable within the past 90 days; the 10-day query limit doesn’t mean older records have disappeared. The report types provide different levels of detail. Report Main use Availability and limits Summary Review sender, recipient and delivery outcome online. Almost immediate; up to 20,000 results. Enhanced summary report Export a CSV file with additional fields, including direction and original client IP address. Can take several hours; up to 100,000 results. Extended report Examine detailed routing and message events in a CSV. Can take several hours; up to 1,000 results. Start with Summary for a single missing email. Choose Extended when the online result doesn’t provide enough routing detail, rather than assuming a larger export is more informative. Enhanced summary and Extended reports require at least a sender, recipient or Message ID. Archived reports typically exclude the most recent 24 hours. Client IP information is available only for the most recent 10 days and through those downloadable report types. Microsoft’s message trace documentation describes the report fields and search options. Read delivery statuses as outcomes, not complete explanations A status identifies the recorded outcome, but the events explain how Exchange Online reached it. Inspect the result for the affected recipient because a message sent to several people can have different delivery outcomes. Use the status to choose the next investigation. Status Meaning Next action Delivered Successfully delivered to the recipient or intended destination. Establish where it was delivered and investigate mailbox handling. Pending Delivery is being attempted or deferred for another attempt. Read the latest deferral event and diagnostic information. Quarantined Held as spam, bulk email or phishing. Review the quarantine reason and applicable policy. Filtered as spam Identified as spam and blocked rather than quarantined. Inspect filtering events before changing controls. Failed Delivery did not complete successfully. Review the failure event and non-delivery report. For outbound mail, successful delivery can mean that the receiving system accepted the message. It does not establish placement in the external recipient’s Inbox. A Delivered result narrows the investigation. It does not establish that the message is still present, visible or unread in the mailbox. Pending also needs context. The latest event matters more than the label alone, particularly when the receiving system is temporarily refusing connections. Use message events to identify the cause Open the matching result and review its event sequence. Submission, transfer, delivery, deferral and filtering events can show where processing changed, including whether a transport rule or spam filter acted on the message. When delivery succeeded but the email is missing Establish the final destination, then inspect Junk Email, Deleted Items, inbox rules and mailbox forwarding. A clean-looking Outlook
Why Microsoft Entra Conditional Access blocks valid users
Microsoft Entra Conditional Access blocks legitimate users when their sign-in fails a policy requirement, even if their password and multifactor authentication (MFA) are correct. Common causes include missing device-compliance information, unsupported authentication methods, unexpected network locations and overlapping policies. A valid account does not automatically satisfy every access condition. The correct response is to identify the failed requirement before changing policy scope or adding an exclusion. Start with the sign-in evidence, then distinguish a configuration problem from a control operating as intended. What Microsoft Entra Conditional Access evaluates Conditional Access is a policy-based feature in Microsoft Entra ID, formerly called Azure AD Conditional Access. It evaluates signals such as identity, device health, location and risk in real time when making access decisions. Policies can allow access, block it, or require additional controls such as MFA or device compliance. That does not mean every existing session is reassessed continuously; behaviour depends on the application, token and supported session controls. These 5 components explain what a policy targets and requires. Component What it determines Users and Groups Which employees, administrators or guests are included or excluded. Cloud Apps and Services Which resources are protected, shown as target resources in the editor. Conditions When the policy applies, including platform, location, client type and risk. Access Controls Whether access is blocked or requires controls such as MFA or compliance. Session Controls How supported sessions behave after access, including reauthentication requirements. The important distinction is between authentication and authorisation. Proving identity does not establish that the device, connection or authentication method meets the resource’s requirements. Why a legitimate sign-in can fail Device ownership does not establish compliance A company-owned laptop can fail a compliance requirement. Microsoft Intune assesses configured standards, which can include encryption, antivirus protection and supported operating-system versions, depending on the platform. Entra then uses the reported compliance state. An enrolled device may still be non-compliant, while a browser or application may fail to present the device identity needed for evaluation. Review the Intune finding and the sign-in’s device details together. Repeated password resets will not repair an encryption failure or missing device identity. Personal-device access needs a separate design. Our guidance on Microsoft 365 BYOD security distinguishes mobile app protection from unrestricted access on personal computers. Location and authentication requirements can change the result Location rules normally use the connection’s public IP address, not the employee’s physical presence. VPNs, corporate proxies and mobile networks can therefore produce unexpected results against configured named locations. Country restrictions reduce some unwanted access, but do not prove that an allowed connection is trustworthy. Authentication strength introduces another distinction. Completing SMS-based MFA does not satisfy a policy requiring phishing-resistant authentication. Register and test supported methods before enforcing the stronger requirement. Identify the policy that caused the failure A sign-in error establishes that access failed; it doesn’t identify the correct remedy. Review the affected event, its authentication details and every evaluated policy before changing a grant control or exclusion. Open the actual failed sign-in In Microsoft Entra ID, open the user’s sign-in logs in the Entra admin center and locate the event using its timestamp, application and correlation ID where available. Review the resource, client application, IP address, device information, risk level, authentication details and results for each Conditional Access policy together. Error AADSTS53003 indicates that Conditional Access blocked token issuance, but the policy results establish which requirement needs investigation. Include non-interactive sign-ins where background access fails. An Outlook token request can produce a different result from an interactive browser sign-in. Evaluate every applicable policy Applicable policies combine their requirements. Passing an MFA policy doesn’t override a separate policy blocking the location or requiring a compliant device. An exclusion affects only the policy containing it. Another applicable policy can still block the same account. A result of “Not applied” establishes that the particular policy didn’t apply. It doesn’t prove that MFA or another authentication requirement was unnecessary. Use the Conditional Access What If tool to evaluate policy targeting, but retain the actual sign-in event as evidence of what happened. Create and test policies without a tenant-wide lockout Define the business requirement before opening the policy editor. Record the protected resources, intended users, acceptable devices and recovery arrangements. Use this deployment sequence: Establish emergency access before enforcement. Exclude at least 1 administrator account during testing to reduce lockout risk; maintain the stronger emergency-account arrangements described below. Open the Entra admin center, then Entra ID > Conditional Access > Policies. Select + New policy and give it a descriptive name. Configure users, target resources, conditions and controls. Where multiple grant controls are selected, distinguish requiring all selected controls from requiring any 1. Select report-only mode and review evaluated sign-ins. Microsoft’s report-only guidance explains how to assess policy impact before enforcement. Enable the policy for a pilot group, resolve failures and expand in stages. Retain a documented rollback route. Include iPhones, Android devices, contractors, travelling staff and people using multiple work accounts. A successful test on an administrator’s managed laptop does not establish that those workflows will work. Report-only evaluation cannot demonstrate every user interaction. An enforced pilot remains necessary before wider deployment. Choose controls that match the business task Foundational policies follow zero trust by evaluating identity and context rather than trusting a connection by default. They normally address MFA, privileged access, legacy authentication and access from unmanaged devices. Each requires a defined purpose and deployment sequence that preserves essential work. Microsoft strongly recommends blocking legacy authentication. Its published analysis attributes more than 97% of credential-stuffing attacks and more than 99% of password-spray attacks to legacy authentication protocols. Inventory dependencies first, then block those protocols for most users. Unsupported clients and older integrations may stop working; that doesn’t justify a permanent, organisation-wide exception. For devices, use Intune compliance where the task requires managed endpoints. Maintain a consistent baseline across office, home and travelling users, as discussed in our endpoint security guidance. For guest access, decide whether to accept authentication and device claims from a guest’s home tenant. Otherwise, a
Why Azure Storage accounts expose business files
Azure Storage can expose business files when a storage account allows anonymous access, credentials are leaked or network rules are too broad. Excessive permissions can also expose files held in Azure Storage. Azure Storage security depends on controlling these routes separately; encryption at rest doesn’t prevent someone downloading files through authorised access obtained improperly. The practical priority is to identify which identities, credentials and networks can reach sensitive data. Start with those access paths, then address transport protection, monitoring and recovery. Key takeaways for Azure Storage security Use the following priorities to organise remediation. These are operational priorities, not Microsoft severity ratings. Control area Priority Required action Anonymous access High Disallow anonymous Blob access for confidential data. Identity High Use Microsoft Entra ID and scoped data roles. Credentials High Remove unnecessary keys and shorten SAS lifetimes. Network access High Restrict public connectivity and approve exceptions. Transport Medium Require secure transfer and TLS 1.2. Monitoring and recovery High Collect service logs and test restoration. Apply these controls together. A restricted network does not correct excessive permissions, whilst strong authentication does not remove an anonymous access route. Distinguish public connectivity from public access A publicly reachable storage endpoint does not automatically expose its contents anonymously. Requests normally still require authorisation. Anonymous Blob access becomes possible when the storage account permits it and an individual container has an appropriate public access level. For confidential business files, disable anonymous Blob access on each relevant storage account. This prevents a container owner accidentally making documents publicly readable. It does not invalidate account keys, Shared Access Signatures or Microsoft Entra permissions. Other exposures involve access that remains technically valid: an old integration retains a key, a departed administrator retains permissions, or a shared download link remains usable. Identify an owner for each account, record its business purpose and review access when applications or staff responsibilities change. Our guidance on secure IT defences explains why cloud configuration needs ongoing ownership rather than a one-off deployment review. Replace shared credentials with scoped identities Use Microsoft Entra ID and data roles Prefer Microsoft Entra ID, formerly Azure AD, over Shared Key authorisation wherever the workload supports it. Role-based access control (RBAC) ties permissions to a named user, group or application, rather than possession of an account-wide secret. Apply the principle of least privilege by assigning data roles at the narrowest suitable scope. An application that only downloads blobs normally needs Storage Blob Data Reader, not Storage Blob Data Owner. Protect human administrator access with multifactor authentication and appropriate Conditional Access policies. Those controls don’t protect requests authenticated directly with a storage account key. Remove unnecessary account keys Azure generates 2 account access keys when an account is created. These credentials provide broad access and are difficult to attribute to an individual when shared between applications. Rotate remaining keys periodically and replace dependencies methodically. Regenerating a key immediately invalidates credentials signed with it, so an unplanned rotation can interrupt production. Disable Shared Key access after migrating supported dependencies. Microsoft’s storage security recommendations favour identity-based authorisation over account keys. Use managed identities for applications A managed identity lets supported workloads authenticate without distributing application secrets. Azure manages and rotates its credentials. A system-assigned identity is deleted with its associated workload resource. A user-assigned identity has an independent lifecycle. Both still need carefully scoped permissions, an accountable owner and removal when their purpose ends. Give every SAS token a defined lifetime A Shared Access Signature (SAS) delegates access through a signed token. Anyone possessing a usable token can exercise its permissions, subject to its restrictions. A token copied into an email, browser history or support ticket can therefore become an exposure route. Grant only the required service, resource and permissions. Microsoft recommends an expiry of 1 hour or less for a service SAS that is not associated with a stored access policy. This is not a universal limit for every SAS scenario. Configure an account SAS expiration policy and monitor tokens that exceed the intended lifetime. Prefer user-delegation SAS for Blob access when delegation is necessary, or managed identity when the application supports direct authentication. Disabling Shared Key blocks account-key authorisation, including account and service SAS. It does not block supported Microsoft Entra access or user-delegation SAS. Restrict the network paths into storage Choose private connectivity or a restricted public endpoint A private endpoint assigns a private IP address within a virtual network. Traffic travels over the Microsoft backbone rather than the public internet. Applications also need working private DNS and connectivity to that network. Creating a private endpoint does not disable the public endpoint. Restrict public network access separately. Where public connectivity remains necessary, set the default network action to Deny and use firewall rules to allow approved sources while denying unnecessary connections. Rules can allow specified public IP ranges, virtual-network subnets, resource instances or supported trusted Azure services. Confirm clients use HTTPS when they connect to the storage service. These exceptions don’t remove authentication requirements. Document the business dependency behind each exception rather than enabling broad access to resolve an application failure. Microsoft’s Blob Storage 403 troubleshooting guidance distinguishes network rejection from authentication and permission failures. Diagnose the cause before reopening access. Coordinate multiple accounts and restrict copying A Network Security Perimeter provides shared inbound and outbound rules across supported platform-as-a-service resources, including storage accounts. It suits environments where individually maintained account rules become inconsistent. In Enforced mode, public traffic is blocked unless perimeter rules permit it. Private-endpoint traffic is outside those perimeter access rules, so private connectivity still needs separate governance. Azure also provides a preview control for permitted copy-operation sources. It can restrict sources to the same Microsoft Entra tenant, or use the PrivateLink option for accounts linked to the same virtual network as the destination. Treat this as an additional copy restriction, not a replacement for permissions or network controls. Protect traffic and stored data separately Require secure transfer and TLS 1.2 Enable Secure transfer required so storage REST requests using HTTP are rejected and clients
Microsoft 365 audit retention: what admins should check
Microsoft 365 audit retention is normally 180 days under Audit (Standard). Audit (Premium) provides 1-year retention for qualifying Exchange, SharePoint, OneDrive and Microsoft Entra records, but the entitlement depends on the user generating the activity. An E5 subscription somewhere in the tenant does not give every account the same retention. Per-user licensing, record type and matching policies determine which period applies. Start by separating the default duration from the policies and licences that can change it. Key Takeaways Audit (Standard) normally retains records for 180 days. Audit (Premium) retains qualifying Exchange Online, SharePoint, OneDrive and Microsoft Entra records for one year when the user who generated the activity has an eligible licence. An E5 subscription in the tenant doesn’t give every user the same retention. The generating user’s licence, the record type and the matching policy determine the period. When custom policies match the same record, the policy with the lowest numerical priority wins. Policies aren’t retroactive, and a custom policy can shorten retention by taking precedence over the default. Microsoft Entra sign-in logs and Insider Risk alerts and cases have separate retention rules. External archiving requires continuous collection, monitoring and a tested retrieval process. Compare the default retention periods Audit (Standard): 180 days The default audit log retention policy for Audit (Standard) retains audit records for 180 days. The older 90-day period applied to records generated before 17 October 2023; it is not the standard duration for newly generated records. Records generated by users without qualifying E5-level or Audit (Premium) entitlement, and by guest users, normally receive 180-day retention. A longer policy does not remove the licensing requirement. Audit records describe supported activity. They do not provide an independent means of restoring deleted messages or documents, which requires separate consideration of Microsoft 365 backup and recovery. Audit (Premium): 1 year for qualifying workloads Audit (Premium) has a default, non-editable policy retaining qualifying Exchange Online, SharePoint, OneDrive and Microsoft Entra audit records for one year. Other workloads normally remain at 180 days unless an applicable custom policy extends them. Microsoft’s audit retention policy guidance also distinguishes non-user activity. Records generated by service principals and system events have fixed 1-year retention that custom policies do not change. Match each retention period to its licence Retention is assessed against the entitlement of the user whose activity generates the record. An administrator’s E5 license doesn’t extend retention for activity performed by colleagues without that entitlement. The available periods have different licensing requirements. Retention period Licensing requirement 180 days Audit (Standard); also the normal period for guests and users without qualifying Premium entitlement 7 or 30 days Microsoft 365 Enterprise E5 6 months, 9 months or one year Eligible Audit (Premium) licensing 3, 5 or 7 years E5 plus the 10-Year Audit Log Retention add-on 10 years E5 plus the 10-Year Audit Log Retention add-on Eligible Premium entitlements include Microsoft 365 E5, Office 365 E5 and qualifying audit add-ons. The 10-year add-on license is also required for the 3-, 5- and 7-year options; selecting a shorter multi-year duration doesn’t avoid that requirement. Budget for the users whose activity generates audit records that need extended retention. External archiving introduces separate collection, storage and administration costs. Choose the period based on investigation needs, contractual obligations and the organisation’s documented retention schedule. A 7-year policy defines a technical retention period; it doesn’t establish that every audit record must legally be kept for 7 years. Understand which audit retention policy wins Priority takes precedence over duration An organisation can create up to 50 custom audit log retention policies. Priority values run from 1, the highest, to 10,000, the lowest. When multiple custom policies match a record, the policy with the lowest numerical priority wins. Custom policies also take precedence over the default audit log retention policy. The longest period does not automatically take priority. For a qualifying E5 user with the add-on, a matching Microsoft Teams policy retaining records for 10 years at priority 100 takes precedence over a matching 1-year policy at priority 200. Reverse those priorities and the 1-year policy wins. Review user scope, record types and priority together. New policies do not extend earlier records Audit retention policies are not retroactive. A policy created today cannot extend retention for records generated before its creation, even when those records remain searchable. Assign the required licences and establish the policy before generating activity that needs longer retention. An upgrade cannot reconstruct records that have already expired. A custom policy can shorten retention because it overrides the default. Treat priority changes as changes to evidence preservation, not routine housekeeping. Create and manage the policy in Microsoft Purview Configure the policy in the portal Use an account with the permissions required to manage audit retention policies. Define the intended users, activities, duration and priority before creating the policy. In the Microsoft Purview portal, follow these steps: Select Solutions, then Audit. Open Audit retention policies and select Create audit retention policy. Enter a meaningful name and description, then select the relevant users and record types. Choose the retention duration and assign a priority that reflects existing matching policies. Save the policy and review its scope alongside the other policies in the dashboard. A description should explain the business requirement and policy owner. Naming a policy after a department alone doesn’t explain why its records need a particular duration. Manage policies through PowerShell Connect to Security and Compliance PowerShell using Connect-IPPSSession. Create policies with New-UnifiedAuditLogRetentionPolicy. Microsoft’s documented Teams example uses -RecordTypes MicrosoftTeams -RetentionDuration TenYears -Priority 100. These settings define the workload, duration and precedence; the relevant users still need qualifying licensing. Use Get-UnifiedAuditLogRetentionPolicy to review the configured policies. Document approved changes to scope, duration and priority so another administrator can reconstruct why a particular policy applies. Portal configuration and PowerShell configuration affect the same retention controls. Using a script doesn’t bypass licensing or make a policy retroactive. Verify coverage without assuming a search proves retention A saved policy confirms configuration, not complete coverage. Review Microsoft 365 audit retention against the
Entra emergency access accounts: prevent admin lockout
In Microsoft Entra ID, formerly Azure AD, emergency-access accounts (also called break-glass accounts) reduce administrator lockout risk. Their authentication and recovery arrangements must remain independent of normal administrator access. Create at least 2 cloud-only accounts with permanent Global Administrator permissions and phishing-resistant MFA. Conditional Access exclusions do not remove Microsoft’s mandatory MFA requirement. A password stored in a safe is no longer a complete recovery plan. The account must also have a working authentication method, accessible credentials and tested monitoring. Start by separating those requirements. Key takeaways for emergency access Use these controls as the configuration baseline. Control Required configuration Identity At least 2 cloud-only accounts using the tenant’s .onmicrosoft.com domain Permissions Permanent active Global Administrator, not PIM-eligible Authentication FIDO2 passkeys or certificate-based authentication configured for MFA Credential custody Separate secure storage, documented custodians and accessible recovery instructions Monitoring Alerts for successful sign-ins, failed attempts and associated audit events Testing Each account at least every 90 days These accounts provide a controlled Break-Glass capability and should remain unused outside authorised testing and genuine recovery. Understand mandatory MFA and Conditional Access exclusions Why excluded accounts still receive MFA prompts Microsoft’s mandatory MFA enforcement explicitly includes emergency-access accounts. Excluding an account from every tenant Conditional Access policy does not exempt it from this separate enforcement. Microsoft’s mandatory MFA documentation describes the gradual rollout: Phase 1 began in October 2024 for the Azure, Entra and Intune administration portals. Microsoft 365 admin centre enforcement began gradually in February 2025. Phase 2 began on 1 October 2025 for management clients and API operations that create, update or delete resources. Read operations are outside that phase. These dates mark rollout starts, not simultaneous enforcement across every tenant. What sign-in logs can establish Open the sign-in event and review the application, authentication details and Conditional Access results together. Policies marked “Not Applied” establish that those policies did not apply; they do not prove that MFA was unnecessary. Mandatory MFA can explain a prompt despite those exclusions. Other authentication and registration mechanisms can also interrupt access. Device-compliance requirements used for Microsoft 365 access on personal devices can obstruct recovery if emergency accounts depend on the same managed-device infrastructure. Design exclusions around identified lockout risks rather than assuming an MFA exclusion is sufficient. Create 2 cloud-only emergency accounts Microsoft’s emergency-access account guidance recommends cloud-only identities and permanent active Global Administrator assignments. This keeps recovery independent of on-premises synchronisation, federation and privileged-role activation. Create 2 separate users directly in Microsoft Entra ID using the tenant’s .onmicrosoft.com domain. Keep each identity individually controlled, and don’t synchronise accounts from Active Directory or associate them with individual employees. Record each account’s user principal name and immutable object ID. Use the object IDs in monitoring rules so display-name changes don’t break detection. Assign Global Administrator as permanent active. Don’t make the assignment eligible through Privileged Identity Management (PIM), because activation adds another dependency during recovery. Review Conditional Access coverage and document the exclusions needed to prevent lockout. Keep both accounts enabled and available for their intended purpose. Update legacy Azure AD recovery runbooks to use the current Microsoft Entra ID terminology and process. Don’t use these identities for email, browsing, automation or routine administration, or as shared accounts for everyday administration. Normal administrators should retain separate, appropriately restricted administrative accounts. A Microsoft 365 security assessment should distinguish these documented emergency privileges from unnecessary standing permissions elsewhere. Register authentication and protect credential custody Prefer device-bound hardware credentials Use a FIDO2 hardware security key where practical, or certificate-based authentication configured to satisfy MFA. A certificate doesn’t automatically provide multifactor authentication merely because it’s installed. For hardware keys, enable the relevant passkey authentication method for the emergency accounts in Entra authentication-method policies. Complete registration through the account’s security information page using an approved bootstrap method, then test a fresh administrative authentication. Microsoft’s Entra passkey documentation explains the supported authentication model. A hardware key keeps its credential device-bound; a synced passkey introduces dependencies on its syncing provider and recovery process. Register and securely store spare keys. If using certificates, document certificate expiry, trust configuration and revocation dependencies. A recovery credential that expires unnoticed can leave an apparently prepared account unusable. Separate storage without making recovery impractical Generate a long, random, complex password for each account. Password material can be split between sealed envelopes, separate safes or disaster-recovery kits. This protects custody; it doesn’t replace MFA. Keep duplicate recovery material in separate sealed envelopes with authorised custodians. Record who can retrieve each password component, key and PIN. Don’t store every recovery item in a password vault accessible only through the tenant being recovered. Maintain a custody register covering storage location, authorised holders and access history. When a custodian leaves, review these arrangements alongside the Microsoft 365 leaver access checklist, without deleting the organisation-owned emergency identity. Remove unexpected registration dependencies A successful passkey authentication doesn’t establish that every security-information registration requirement has been satisfied. Combined registration can interrupt access because of Conditional Access, per-user MFA, Identity Protection, self-service password reset (SSPR) or other MFA policies. Administrator SSPR uses a predefined 2-gate policy. It can request Microsoft Authenticator plus another method, even where a FIDO2 credential already satisfies the account’s authentication requirements. Microsoft’s emergency-account registration discussion addresses this distinction. Administrators can disable administrator SSPR tenant-wide using Microsoft Graph PowerShell: Update-MgPolicyAuthorizationPolicy -AllowedToUseSspr:$false This affects administrator SSPR across the tenant, not just the emergency accounts, and can take up to 60 minutes. It doesn’t disable mandatory MFA or remove unrelated registration requirements. Treat that command as a policy decision, not a standard preparation step. First identify which policy or process is triggering combined registration. Test that registration path in a fresh browser session before changing tenant-wide recovery settings, rather than relying on an existing authenticated session. Monitor every sign-in and audit event Monitoring must cover sign-in attempts, including successful and failed access, not merely successful recovery. A failed attempt can indicate a guessed username, exposed password or deliberate targeting of a highly privileged account. Send identity logs to Log Analytics Configure Entra
Why Entra app registrations fail when secrets expire
Microsoft Entra ID, formerly Azure AD, rejects fresh token requests that use an expired credential. The app registration remains in place, but integrations using that credential can’t authenticate until a replacement is configured. Creating a new secret alone doesn’t restore service: the application, script or connector must receive its new value. Entra client secret expiration can interrupt website sign-in, automated reporting or Exchange Online mail sending. Existing access tokens may continue working temporarily, which can delay the visible failure. Start by identifying the failing credential and every service that uses it. Key Takeaways An expired Entra client secret blocks fresh token requests that use it, but previously issued access tokens may keep working until they expire. Creating a replacement secret doesn’t update the applications that use it. Copy its value when it appears, store it securely and update every dependent service. Use the Application (client) ID to identify the app in authentication requests, and the registration’s Object ID for the Microsoft Graph PowerShell command. Keep the old secret during deployment when it’s still valid, then test fresh authentication and the actual business operation before removing it. Assign an owner to each credential and monitor expiry dates with reminders that reach the responsible people. What Entra client secret expiration actually breaks The application cannot prove its identity A confidential application presents its credential to Microsoft Entra ID when requesting tokens. The credential authenticates the application rather than the person using it. Once that secret expires, Entra ID rejects authentication attempts using it. The error commonly includes AADSTS7000222, which identifies expired client secret keys. The registration, API permissions and consent normally remain unchanged. For OpenID Connect sign-in, the application may fail when exchanging an authorisation code for tokens. An unattended mail-sending process may fail when requesting an application token. Neither problem is resolved by resetting a user’s password. Cached tokens can delay the symptoms Secret expiry does not automatically invalidate every access token already issued. A running service may continue until its token expires, whilst a restarted instance fails immediately. This explains why an integration can appear healthy after the expiry time, then fail without another configuration change. Test a fresh token request rather than relying on an existing session or a previously successful scheduled job. Identify the credential and every dependent service Separate the application identifiers Use the failed request’s client ID to locate the correct registration. Similar display names aren’t reliable identifiers, particularly where development and production applications coexist. These identifiers have different purposes. Identifier Purpose Application (client) ID Identifies the application in authentication requests Registration object identifier Identifies the registration object used for Graph management commands Secret ID Identifies a credential entry, but isn’t its authentication value Take the registration’s Object ID from its Overview page. An enterprise application’s service principal has a separate Object ID, so don’t substitute it. Find consumers before changing credentials Review deployment settings, Azure App Service configuration, Function Apps, automation accounts, scheduled tasks, CI/CD variables and connector settings. Search configuration references using the client ID, rather than exposing the secret in searches or support tickets. Sign-in logs help identify workloads, but don’t provide a complete inventory of every configuration holding a secret. Infrequent jobs may have no recent activity. Record the application owner, technical owner, deployment location and recovery procedure. Ownership also needs transferring when administrators leave; our Microsoft 365 leaver checklist covers connected applications and other access that ordinary account closure can miss. Replace the secret in the Entra admin centre There is no in-place option to renew client secret credentials. Instead, create a new client secret on the same app registration, then deploy its value to each dependent service. This preserves the application’s identity and permissions. A separate registration would have a different client ID and could require new consent. Follow These Steps: Open the Azure portal and select the Microsoft Entra admin center for the correct tenant. Go to Identity > Applications > App registrations, then select the application. Open Certificates & secrets > Client secrets > New client secret. Enter a description that identifies the consuming service, choose an expiration date and select Add. Copy the new client secret value immediately into an approved secret store, then update the dependent application. The portal offers 6 months (Recommended), 12 months, 24 months or Custom. Its maximum is 24 months, and a custom date cannot exceed 2 years. Microsoft recommends a lifetime of less than 12 months in its client secret lifetime guidance. The secret value is displayed only immediately after creation. You can’t retrieve it after leaving the page. If you didn’t capture it, create another secret and remove the unused credential. Copy the Value, not the Secret ID. Store it in Azure Key Vault or another approved credential store, rather than email, a ticket or an unrestricted document. A shorter lifetime reduces exposure, but it also requires a reliable rotation process. Choosing 24 months only postpones that requirement. Create a replacement with Microsoft Graph PowerShell The Microsoft Graph PowerShell module creates a new password credential using the registration’s unique identifier. The ApplicationId parameter name is easy to misread: for this command, supply the registration’s Object ID, not its Application (client) ID. Run the following in an authorised administrative session: Microsoft’s Add-MgApplicationPassword documentation includes the 6-month credential pattern. The returned $newSecret.SecretText contains the replacement value. Transfer it directly into the approved secret store through a controlled process. Avoid writing the complete response into transcripts, pipeline logs or shared terminal output. The requested scope requires appropriate consent and administrative authorisation. Use a controlled account with the necessary role, then disconnect the session after completing the change. This command doesn’t update the consuming application’s configuration. It also doesn’t remove the old secret. Both actions remain part of the rotation procedure. Switch consumers before removing the old secret Use an overlap period where possible If the existing secret is still valid, retain it whilst deploying the replacement. Multiple credentials can coexist on an app registration, which allows consumers to move without a simultaneous
Passkeys vs authenticator apps for business logins
Passkeys provide stronger protection against credential phishing than authenticator app codes because they are tied to the genuine service. For business logins, use passkeys where supported and password-based multi-factor authentication where they are not. Choosing between passkeys and authenticator apps also depends on device ownership, recovery arrangements and administrative control. Phishing resistance is the main distinction, but neither method protects every route into an account. Start by separating how each works from what its product label suggests. What passkeys and authenticator apps actually do Passkeys replace the password with cryptographic proof A passkey uses public-key cryptography through WebAuthn. Registration creates a private key and a public key, which together form a pair of cryptographic keys. The private key stays on a device or with a supported provider; the service registers the public key. During sign-in, the device signs a challenge. The service verifies the signature using the public key, and the private key is never transmitted. A fingerprint, facial recognition or device PIN normally authorises its use. Biometrics stay on the device. The FIDO Alliance’s passkey guidance explains this passwordless model. Synced credentials can be available across approved devices, whilst device-bound credentials stay on a particular device or hardware key. Authenticator codes add another factor to a password Google Authenticator, Microsoft Authenticator and Authy generate a time-based one-time password (TOTP), usually a 6-digit code. The app and service share a secret established during enrolment. Codes normally work without a mobile signal, and they supplement account passwords rather than replace them. Multi-factor authentication (MFA) combines at least 2 factor types: something you know, something you have and something you are, such as a fingerprint. Two-factor authentication (2FA) uses exactly 2; MFA covers 2 or more. A locally verified credential can combine possession with biometrics or a PIN in 1 sign-in step. This supports passwordless authentication, replacing a password followed by a separate code. Our guide to business passkeys and FIDO2 covers wider deployment considerations. Passkeys vs authenticator apps at a glance The comparison below concerns rotating authenticator codes, rather than every feature available within an authenticator app. Consideration Passkeys Password plus authenticator code Password required Normally no Yes Fake-site credential capture Domain-bound and phishing-resistant Codes can be captured and relayed Routine sign-in Local biometric or PIN approval Password, then code Compatibility Growing, but incomplete Widely supported Device loss Recovery depends on storage and backup arrangements Recovery depends on app backup or another registered method Business control Depends on provider and identity policy Depends on service and app configuration Passkeys remove the reusable password from that sign-in path. Authenticator codes substantially improve password-only security, but they remain transferable information that someone can enter into the wrong page. A hardware security key such as a YubiKey can hold a device-bound credential or act as an additional authentication factor. Its role depends on the service and registration method. Where phishing protection stops Fake login pages can relay authenticator codes An attacker can place a real-time proxy between an employee and a genuine service. The employee enters a password and current authenticator code into the imitation page, and the attacker forwards both before the code expires. Passkeys are bound to the registered service’s domain. A lookalike website cannot request the genuine site’s passkey just because its branding looks convincing. The NCSC’s credential security comparison explains the underlying distinction. Text message codes and email codes are weaker fallback options because messages or receiving accounts can be intercepted or compromised. SMS also carries SIM-swapping risk, where an attacker takes control of the phone number. Secure authentication does not protect every session Passkeys do not remove malware, correct excessive permissions or prevent an employee approving a fraudulent payment. An attacker who steals an existing browser session may avoid the normal sign-in process altogether. Registering this credential does not remove an account’s weaker fallback methods. Recovery and alternative sign-in paths need their own controls. Maintain endpoint protection, access reviews and session monitoring alongside stronger authentication. Our explanation of the ClickFix browser session threat covers attacks that target access already established in the browser. Which business systems can use passkeys? Microsoft environments need administrator configuration Microsoft Entra ID supports FIDO2 passkeys, including supported credentials in Microsoft Authenticator and hardware security keys. Microsoft 365 accounts authenticated through Entra can use these methods where policies and the sign-in environment support them. Microsoft Authenticator needs careful terminology: a passkey stored in the app differs from its rotating codes or push approvals. Microsoft’s Entra passkey documentation describes the authentication method. Our guidance on Microsoft Entra passkeys covers the related business planning. Other services still require a mixed approach Google Accounts and GitHub support passkeys, but support remains incomplete across business applications. A payroll portal, specialist database or older remote-access system may still require a password and authenticator code. Use the strongest method available for each service. Where supported, centrally managed single sign-on can reduce separate credentials and apply consistent access policies. It doesn’t make every connected application phishing-resistant automatically. Flag systems that can’t support modern authentication for replacement, isolation or migration. Shared devices, browser versions and personal-phone restrictions also affect which credential options are practical. Set up each method without weakening recovery Register passkeys through the genuine service Open the service directly, sign in and select its option to add a passkey in account security settings. Choose an approved device, hardware key or password manager, then complete local verification. The service records the public key. If you select a syncing provider, the encrypted credential can become available on other authenticated devices through that provider. For Microsoft Entra, administrators must enable the relevant authentication methods and policies before users enrol. Test a fresh sign-in and an approved backup route before removing the previous method. Successful registration doesn’t prove recovery works. Enrol authenticator codes and protect the setup secret Select authenticator-app verification in the service’s security settings. Scan its enrolment QR code with the approved app, then enter a generated code to complete registration. Treat the QR code as a secret. Anyone who obtains the
Invoice fraud: a 2-person payment change check
A 2-person payment change check reduces invoice fraud risk by separating supplier verification from approval of new bank details. One person confirms the request through a previously trusted contact; another reviews the evidence before authorising the change. Two approvals of the same email are not independent verification. The control works only if staff cannot bypass it through urgency, seniority or system permissions. Start with the payment change itself, then connect it to invoice checks, account security and a response procedure. Key takeaways Confirm bank detail changes through a previously established supplier contact, never by replying to the requesting email. Require a second person to review the verification evidence before approving the change. Keep invoice approval separate from supplier creation and payment release, with named cover for absent staff. How invoice fraud reaches accounts payable Invoice fraud uses false, altered or duplicate invoices to obtain money an organisation doesn’t owe. A payment request can divert money for a genuine purchase to a criminal’s account; fraudulent payment requests are payment fraud, not false invoices. The distinction affects the checks required. A correct purchase order and confirmed delivery don’t establish that replacement bank details belong to the supplier. These 5 common forms require different checks: Fraud type What accounts payable should examine Fake or fictitious invoices Whether the supplier, order and purchase are genuine. A fake vendor can be created to submit a false bill. Supplier impersonation Whether payment instructions came from an independently verified supplier contact. Inflated invoices Whether quantities, prices and charges match the agreement. Duplicate invoices Whether the same obligation has already been recorded or paid. A duplicate invoice may be submitted with a changed reference. Internal billing schemes Whether employees can create suppliers, approve invoices or conceal related-party payments without scrutiny. Warning signs include a missing purchase order, emailed bank changes shortly before payment, vague descriptions and amounts just below the approval threshold. Supplier impersonation can involve a message that appears to come from a real supplier. Urgency and secrecy should trigger a pause, but their absence doesn’t establish legitimacy. A compromised supplier mailbox can carry genuine correspondence alongside fraudulent instructions. Our explanation of business email compromise covers why checking the sender’s address alone leaves a gap. What the loss figures do and do not show Older international research illustrates the scale, but it should not be presented as a forecast for a UK business. A 2022 Forbes article reported more than 34,000 invoice fraud cases across 2,750 surveyed businesses. It also reported average annual losses of $280,000 amongst middle-market companies. Ardent Partners’ 2024 accounts payable research found that 37% of AP teams experienced increased fraud attacks. Basware also reports that a quarter of finance professionals could not estimate their organisation’s invoice fraud losses. The examples extend beyond bank-detail changes. Basware describes Detroit Metro Airport paying a contractor $1.5 million for an ice-melting product that was never purchased. Basware also cites paper cheques accounting for 40% of US business-to-business payments, leaving cheque interception relevant there. That figure is US context, not a UK payment benchmark. For a UK finance team, the practical question is whether someone can alter a supplier record and influence the next payment without independent scrutiny. Set up a 2-person payment change check A fraudulent PDF can retain the correct supplier name, invoice number and amount while changing only the payment destination. This invoice fraud can enable payment fraud by diverting a legitimate payment to an attacker, even when the invoice matches. 1. Confirm the change through a trusted route The first person places the payment on hold and carries out vendor verification by contacting the supplier using a number recorded during verified onboarding or on an earlier, trusted contract. Don’t use the number in the change request, its attachment or its email signature. Confirm who requested the change, why it’s needed and the complete replacement account details. Record the contact, number used, time, outcome and evidence. A familiar voice isn’t sufficient proof. Our guidance on AI-generated CEO voice scams explains why voice instructions also need independently initiated verification. If the genuine supplier denies requesting the change, retain the original bank record, hold payment and escalate the message. 2. Review the evidence before approving the update The second person reviews the verification record and compares the confirmed details with the proposed supplier amendment. This separation of duties keeps the verifier and approver as different people. Reopening the same email doesn’t satisfy this requirement. Record both identities and approval times. Restrict supplier amendments to authorised users and retain the previous details in the audit trail. Name deputies before holidays or sickness create pressure. If the verifier or approver is unavailable, hold the change rather than allowing self-approval. Apply this rule regardless of amount. A small initial payment can still establish an attacker-controlled beneficiary for later transfers. Check the invoice and payment separately The bank change check does not identify every false bill. Invoice verification must establish that the debt exists, whilst payment approval must establish that the destination and amount are authorised. Use this check before releasing payment: Check Evidence required Hold payment when Supplier identity Approved supplier record and verified onboarding. The supplier is unknown or unexpectedly changed. Purchase authorisation Invoice matched to the purchase order. Prices, quantities or authorisation differ. Delivery Goods receipt or documented service acceptance. Delivery cannot be confirmed. Duplicate detection Invoice history and payment records. References, amounts or billing periods overlap. Payment destination Approved bank record and change-verification evidence. Details differ without completed approval. Two-way invoice matching compares the invoice with the purchase order. Three-way matching adds the goods receipt. For services, retain documented acceptance. Where purchasing legitimately operates without purchase orders, require an approved exception and equivalent evidence. A duplicate invoice may have a reformatted or changed reference, so compare the supplier, amount, date and billing period, not just the invoice number. Separation of duties means the invoice approver cannot also create the supplier or release the payment. Enforce that distinction through permissions, rather than relying only on a written
