DEV Community: Songeziwe Fayindlala

South Africa Accounts for 92% of Africa’s Ransomware Detections. Here’s What IT Teams Should Learn From It

Songeziwe Fayindlala — Mon, 31 Aug 2026 20:48:12 +0000

South Africa has become a major focal point in Africa’s ransomware landscape.

According to INTERPOL’s African Cyberthreat Assessment Report 2026, South Africa accounted for 92% of ransomware detections recorded across Africa in 2025, based on TrendAI telemetry. That figure is striking, but it needs context: it represents detections, not proof that 92% of all ransomware attacks on the continent occurred in South Africa.

Even with that distinction, the signal is impossible to ignore.

South African organizations are operating in an environment where highly connected businesses, government institutions and critical services are attractive targets. And the most useful lessons are not found in the percentage itself. They are found in the incidents behind it.

Recent attacks against organizations such as the National Health Laboratory Service (NHLS) and the South African Weather Service (SAWS) demonstrate that ransomware is no longer simply an endpoint-security problem.

It is a business continuity problem.

The 92% Statistic Is a Warning, Not the Whole Story

A common reaction to a statistic like this is to ask why South Africa is being targeted more heavily than other African countries.

There is a more useful question for IT leaders:

Why do some attacks become business crises while others remain contained security incidents?

South Africa's highly connected digital economy means attackers have access to valuable systems and data, while organizations often depend heavily on technology to deliver essential services.

INTERPOL's latest assessment also highlights a wider cyber-threat environment involving phishing, business email compromise, vulnerabilities and increasingly automated attacks. South Africa accounted for 70% of Africa's business email compromise detections in 2025, according to the same TrendAI telemetry.

The lesson is that ransomware rarely exists in isolation.

It often begins with the things security teams already worry about: a stolen credential, a phishing message, an exposed vulnerability or excessive privileges.

The Incidents Behind the Headline

The NHLS ransomware attack in June 2024 is one of the clearest examples of how a cyber incident can quickly become an operational emergency.

The attack encrypted systems used by the National Health Laboratory Service, affecting internet and intranet services, the laboratory information system and access to historical laboratory data. Because NHLS provides diagnostic pathology services to more than 80% of South Africa's population, the disruption extended far beyond an internal IT environment.

The important lesson is not simply that healthcare was attacked.

It is that critical services continued to depend on systems that were suddenly unavailable.

The South African Weather Service experienced a similar reality after a January 2025 cyberattack that affected most of its systems. Its annual report records that data recovery continued while the organization used alternative mechanisms to distribute severe-weather warnings and information.

That is what ransomware resilience ultimately looks like.

Not preventing every incident.

Continuing to operate when prevention fails.

The Attack Path Is More Important Than the Ransom Note

Ransomware tends to receive attention when files are encrypted and a ransom demand appears.

Defenders should be looking much earlier.

A simplified attack path looks like this:

Initial Access → Identity Compromise → Lateral Movement → Privilege Escalation → Data Access → Encryption/Disruption

The important part is the middle.

An attacker who reaches the encryption stage has often already succeeded at several earlier stages.

That means an organization's security programme cannot depend entirely on detecting ransomware at the endpoint. It needs visibility into the behaviors that often precede it.

Unusual sign-ins. Suspicious privilege changes. Unexpected remote administration. Abnormal PowerShell activity. Attempts to disable security tools. Large-scale access to files. Unusual movement between systems.

These signals can provide defenders with something incredibly valuable: time.

And in ransomware response, time is often the difference between isolating one compromised machine and recovering an entire environment.

Identity Has Become a Critical Security Boundary

For organizations using Microsoft 365, Entra ID, Intune and Defender, identity deserves particular attention.

A compromised account can provide an attacker with a much easier path into an environment than attacking every endpoint individually.

That makes strong authentication, Conditional Access, privileged-access management and identity monitoring essential parts of ransomware defense.

Multi-factor authentication is important, but it should not be treated as the finish line.

IT teams should also ask whether privileged accounts are separated from normal user accounts, whether dormant accounts are removed, whether service identities are properly governed, and whether suspicious authentication behavior is being investigated quickly.

The objective is simple:

A compromised account should not automatically become enterprise-wide access.

Backups Are Not the Same as Recovery

Ransomware conversations often end with the phrase:

“We have backups.”

That is not enough.

The better question is:

Can we still recover if the attacker compromises an administrator account and discovers our backup infrastructure?

This is why immutable, isolated and offline recovery mechanisms matter.

The South African Weather Service's post-incident procurement requirements provide a useful example. Its specifications called for capabilities including immutable and air-gapped backups, anomaly detection, malware scanning and Zero Trust controls.

The broader lesson is that backup security must be designed around an attacker who is already inside the environment.

And backups must be tested.

A backup that has never been restored successfully is an assumption, not a recovery strategy.

The Biggest Gap May Be Business Continuity

The NHLS incident exposed another important problem: traditional downtime procedures are not necessarily designed for a cyberattack.

A ransomware event can simultaneously affect applications, authentication, network access, files and internal communications.

That makes cyber resilience fundamentally different from planning for a normal infrastructure outage.

IT teams should be able to answer:

What happens when our primary identity service is compromised?

What happens when our file servers cannot be trusted?

What happens when users cannot access normal collaboration tools?

Which business services must be restored first?

These are not purely technical questions.

They require IT, security, operations and business leaders to agree on priorities before the incident occurs.

From Reaction to Resilience

The biggest mistake South African organizations could make is treating the 92% figure as another alarming cybersecurity headline.

The better response is to use it as a design challenge.

Assume that a credential will eventually be compromised.

Assume that an endpoint will eventually be breached.

Assume that an attacker will eventually bypass one of your controls.

Then ask what happens next.

Can the attacker move laterally?

Can they obtain privilege?

Can they reach the backup environment?

Can they disable security controls?

Can you detect them before encryption begins?

Can you isolate affected systems quickly?

Can the business continue operating?

Can you restore the most critical services in the correct order?

Those questions reveal far more about an organization's ransomware resilience than the number of security products it owns.

What South African IT Teams Should Do Now

The practical response does not need to begin with buying another security platform.

Start by understanding where one compromised identity or device could cause disproportionate damage.

Prioritize privileged identities. Strengthen authentication. Reduce unnecessary administrative access. Patch externally exposed systems quickly. Segment critical services. Protect backup infrastructure from ordinary administrative paths. Centralize security telemetry. Define clear isolation procedures. Test recovery.

Most importantly, run an exercise that assumes the attackers have already bypassed the first layer of defense.

The objective should not be to prove that the security controls work.

It should be to discover what happens when they do not.

The Real Meaning of 92%

South Africa accounting for 92% of Africa's ransomware detections is a statistic worth paying attention to.

But the percentage is not the most important part of the story.

The more important story is what recent incidents have demonstrated: when ransomware succeeds, the consequences can move rapidly from compromised credentials and encrypted systems to disrupted public services, delayed operations and difficult recovery decisions.

That changes the question IT leaders should be asking.

Not:

“How do we stop ransomware?”

But:

“How do we make ransomware less capable of stopping us?”

That is the difference between cybersecurity and cyber resilience.

And for South African IT teams, it may be the most important lesson behind the 92%.

Building Compliance Dashboards in Power BI from the Microsoft Intune Data Warehouse

Songeziwe Fayindlala — Sun, 23 Aug 2026 20:31:10 +0000

Introduction

Managing thousands of corporate devices through Microsoft Intune creates an enormous amount of operational data.

Every day, organizations collect information about devices, users, operating systems, compliance policies, configuration profiles, applications and enrollment activity. The challenge is no longer simply collecting the data. The real challenge is turning that information into something that administrators, security teams and management can understand and act upon.

This is where Microsoft Intune Data Warehouse and Power BI become particularly useful.

The Intune Data Warehouse provides an analytics-oriented view of Intune data, exposed through the OData protocol and organized into related entities. Microsoft describes the model as a star schema, with fact-style activity data connected to dimensions such as devices, users, policies and dates. The warehouse also maintains historical information through daily snapshots, which makes it particularly useful for analyzing trends rather than looking only at the current state.

Power BI then provides the visualization and analytical layer that turns this information into dashboards.

Instead of asking:

“How many devices are compliant?”

we can start asking more useful questions:

“Is compliance improving?”

“Which platforms have the highest non-compliance rate?”

“Which policies are causing the most failures?”

“Are there device groups consistently falling behind?”

“Where should the endpoint team focus first?”

That is the difference between reporting data and using data to make decisions.

What Is the Intune Data Warehouse?

The Microsoft Intune Data Warehouse (IDW) is a reporting and analytics service that exposes Intune information in a machine-readable format.

Microsoft documents the Data Warehouse API as an OData v4.0 service that can be consumed by analytics tools and custom applications. Authentication uses Microsoft Entra ID and OAuth 2.0.

The Data Warehouse contains information across areas such as enrolled devices, device properties and inventory, applications, app protection, configuration policies and compliance policies.

One of its most valuable characteristics is historical context.

Intune takes a daily snapshot at midnight UTC and stores that information in the Data Warehouse. Retention varies between fact tables, with some holding approximately seven days of information, others around 30 days, and some datasets retaining longer historical periods.

This distinction is important.

The Intune Data Warehouse should not be treated as a real-time monitoring platform. It is better understood as a historical analytics source.

That makes it particularly useful for Power BI dashboards where the objective is to identify trends, measure changes and understand the overall health of an endpoint environment.

Why Use Power BI for Intune Compliance?

The Microsoft Intune admin center already provides valuable reporting capabilities.

However, an organization often needs something more tailored to its environment.

A security manager might want a single page showing the overall compliance percentage, non-compliant device count, top failed policies and compliance trend.

An endpoint administrator might need a much more detailed view showing specific devices, operating systems, ownership types and policy states.

Management may not want to see thousands of rows of endpoint information at all. They may simply want to know whether compliance is improving, declining or remaining unchanged.

Power BI makes it possible to build these different perspectives from the same underlying data.

Microsoft itself documents Power BI as a supported way to consume the Intune Data Warehouse and create custom reports. The current Microsoft guidance recommends the OData Feed connector for connecting Power BI to the Intune Data Warehouse.

The Architecture

The architecture is conceptually simple:

Microsoft Intune → Intune Data Warehouse → OData → Power BI → Compliance Dashboard

The important part is understanding what happens between each layer.

Intune remains the operational management platform.

The Data Warehouse provides the historical reporting dataset.

OData provides the standardized interface through which Power BI accesses that dataset.

Power BI then transforms, models and visualizes the information.

The result is a reporting layer that can sit above the endpoint management platform.

Connecting Power BI to the Intune Data Warehouse

The first practical step is getting the tenant's Data Warehouse connection information.

In the Microsoft Intune admin center, Microsoft currently documents the following location:

Reports → Intune Data warehouse → Data warehouse

From there, administrators can retrieve the custom OData feed URL for the tenant.

The URL exposes the Data Warehouse service for the tenant.

In Power BI Desktop, the connection can then be created through:

Get Data → OData Feed

The tenant-specific OData URL is entered, and authentication is performed using an appropriate Microsoft Entra identity. Microsoft documents OAuth 2.0 authentication and notes that access is controlled through Microsoft Entra credentials and Intune RBAC.

This is important from a security perspective.

Power BI is not simply connecting anonymously to a database.

Access to the Data Warehouse is governed by identity and authorization.

An Important Change: The Old Connector

One of the most important considerations when building a new dashboard today is choosing the right connection method.

Microsoft states that the Intune Data Warehouse beta connector in Power BI, commonly referred to as connector v1, is being retired.

Microsoft recommends migrating existing reports to the Intune connector v2 or the OData Feed connector. Reports created after November 2025 already use connector v2 and are not affected by the retirement of connector v1.

For a new custom reporting solution, the OData Feed is therefore a strong option because Microsoft explicitly identifies it as the recommended connector for custom Power BI reporting.

This is one of those details that can easily be missed when following older Intune reporting tutorials.

A dashboard built successfully several years ago may not be the architecture you want to reproduce today.

Understanding the Data Model Before Building Visuals

One of the easiest mistakes to make in Power BI is connecting to a data source and immediately starting to create charts.

The better approach is to understand the data model first.

The Intune Data Warehouse uses a star-schema model.

In simple terms, fact tables contain measurements or activities, while dimension tables provide context for those measurements.

A date dimension tells us when something happened.

A device dimension tells us which device was involved.

A policy dimension tells us which policy was involved.

A user dimension provides context about who is associated with the device or activity.

Microsoft designed the model specifically so analytics tools such as Power BI can work with the relationships between these entities.

This is where Power BI becomes considerably more powerful.

Instead of treating every dataset as an isolated table, the model allows us to ask questions across the environment.

The Data That Matters for Compliance Reporting

Several Intune Data Warehouse entities are particularly useful when designing compliance dashboards.

The devices entity contains information such as device identifiers, operating system, Microsoft Entra device ID, ownership, enrollment information and compliance state references.

The complianceStates entity provides the recognized compliance states, including values such as Compliant, Noncompliant, and InGracePeriod.

For policy-level reporting, the compliancePolicyStatusDeviceActivities entity provides daily counts for states such as compliant, non-compliant, unknown, not applicable, error and devices in a grace period.

The compliancePolicyStatusDevicePerPolicyActivities entity goes a step further by allowing compliance status to be analyzed per policy.

This distinction is extremely useful.

A dashboard that only shows overall compliance might tell you that compliance is 92%.

A dashboard that also shows compliance per policy can explain why the other 8% are not compliant.

That turns a number into an investigation starting point.

Designing the Dashboard Around Questions

A good compliance dashboard should not be designed around the question:

“What charts can I create?”

It should be designed around:

“What decisions should this dashboard help someone make?”

That change in thinking has a major effect on the final product.

For example, an executive dashboard could start with five core indicators:

Total Devices

Compliant Devices

Non-Compliant Devices

Compliance Percentage

Devices Requiring Attention

These metrics should immediately answer whether the environment is healthy.

Below those indicators, a compliance trend can show whether the organization is moving in the right direction.

A platform comparison can show whether Windows, iOS/iPadOS, Android or other device populations are behaving differently.

A policy analysis can identify the policies responsible for the greatest number of failures.

And finally, a detailed device view can provide the operational information needed to investigate individual machines.

Measuring Compliance Percentage Correctly

One of the most important design decisions is how the compliance percentage is calculated.

A simple calculation could be:

Compliance % =
Compliant Devices / Devices Evaluated

But the definition of Devices Evaluated matters.

It may include or exclude devices that are unknown, not applicable or in a grace period depending on the organization's reporting policy.

This means two dashboards can use the same source data and produce different compliance percentages while both calculations appear mathematically correct.

The metric therefore needs a documented business definition.

For example:

Compliance percentage represents the proportion of devices evaluated as compliant, excluding devices marked Not Applicable.

Another organization may choose to treat devices in a grace period differently.

The calculation is not only a Power BI problem.

It is a governance decision.

Creating Useful Power BI Measures

Once the Data Warehouse has been loaded into Power BI, the next layer is the semantic model.

This is where DAX measures become valuable.

For example, a simple compliant-device measure could conceptually look like:

Compliant Devices =
CALCULATE(
    DISTINCTCOUNT(devices[deviceKey]),
    devices[complianceStatus] = "Compliant"
)

A compliance percentage could then be calculated from the relevant compliant and evaluated populations.

The exact DAX implementation will depend on the entities and relationships chosen for the model.

The important principle is to centralize the logic.

Do not create the same calculation independently on five different visuals.

Create the measure once and reuse it.

That makes the dashboard easier to maintain and greatly reduces the risk of inconsistent numbers.

Building the Compliance Trend

One of the strongest advantages of the Data Warehouse is historical analysis.

A single compliance percentage is useful.

A 30-day compliance trend is more useful.

For example, suppose the organization reports:

January: 87%

February: 89%

March: 91%

That tells a different story from an isolated 91%.

The trend demonstrates that the environment is improving.

The opposite can also happen.

A team might report 95% compliance today, but if the trend has fallen from 98% over several weeks, the situation deserves investigation.

The date dimension and daily snapshots make this type of analysis possible. Microsoft specifically documents the Data Warehouse as a historical view of the changing Intune environment.

Identifying the Policies Causing Non-Compliance

This is where the dashboard can become genuinely valuable to an endpoint engineering team.

Instead of showing:

401 non-compliant devices

the dashboard can show:

BitLocker policy — 148 affected devices

OS version requirement — 97 affected devices

Security configuration — 76 affected devices

Password policy — 52 affected devices

Other — 28 affected devices

Now the security or endpoint team has something actionable.

The compliance policy activity entities in the Data Warehouse are specifically designed to provide counts by compliance state and, for certain entities, by policy.

This allows Power BI to move from "How many?" to "Which policy?" and ultimately "What should we fix?"

That progression is what makes a dashboard useful.

Drill-Down: From Management to Endpoint

A well-designed Power BI solution should allow the user to move between levels of detail.

At the highest level, management may see:

92.4% Overall Compliance

Clicking that figure could lead to:

Compliance by Platform

From there:

Compliance by Device Group

Then:

Compliance by Policy

And eventually:

Affected Devices

This is the principle of progressive detail.

The dashboard starts with the answer and allows the user to investigate the reason.

That is much better than forcing the reader to navigate through pages of raw device data.

Using Filters Without Making the Dashboard Complicated

Power BI slicers can make an Intune dashboard dramatically more useful.

Typical filters could include:

Operating System

Platform

Ownership Type

Device Category

Compliance State

Policy

User Group

Date

But there is a balance.

A dashboard with twenty slicers may technically be flexible while being practically unusable.

The goal should be to provide only the filters that support real analytical questions.

A good dashboard makes the important information visible first and places deeper analysis behind sensible filtering and drill-through.

A Dashboard Should Tell a Story

This is one of the biggest lessons I have taken from building technical dashboards.

A dashboard is not a screenshot of data.

It is a story.

A useful sequence could be:

How healthy is the environment?

Then:

Is it getting better or worse?

Then:

Where is the problem?

Then:

Why is the problem happening?

And finally:

Which devices need attention?

That sequence creates a natural analytical journey.

It also aligns with the way different teams consume information.

An executive sees the first page.

A security analyst goes deeper.

An endpoint administrator reaches the device-level detail.

Power BI Performance Matters

A dashboard can be visually impressive and still fail operationally if it takes too long to load.

This is particularly important when working with endpoint data because device populations can become large.

The Data Warehouse contains fact-style activity tables that can grow significantly, while some datasets have relatively limited retention windows. Microsoft's documentation notes that fact tables can become large and commonly have shorter retention periods than dimension tables.

This makes data modelling important.

Instead of bringing every available entity into Power BI, only load the information that contributes to the reporting objectives.

Keep relationships deliberate.

Use appropriate measures.

Avoid unnecessary calculated columns.

Filter historical data where the business requirement allows it.

And design the semantic model before building dozens of visuals.

Power BI performance is often won in the model long before the report page is created.

Security and Access Control

The Data Warehouse contains operational information about an organization's devices and users, so security cannot be an afterthought.

Microsoft states that Intune Data Warehouse access is controlled through Microsoft Entra credentials and Intune RBAC. Intune administrators have access by default, while additional users can be granted appropriate Data Warehouse permissions through Intune roles. Microsoft also documents user-less application authentication for supported scenarios.

This means the Power BI solution should be designed with least privilege in mind.

Not everyone who can view a compliance percentage needs access to device-level information.

A management audience may only need aggregated metrics.

An endpoint team may require device details.

A security team may require more granular investigation capability.

The Power BI access model should reflect those requirements rather than simply giving everybody access to everything.

Refresh Strategy

The refresh strategy needs to reflect the characteristics of the Data Warehouse.

Because the warehouse uses daily snapshots, a dashboard built on top of it should not be presented as a real-time endpoint monitoring solution.

That does not make it less valuable.

It simply means the dashboard is designed for a different purpose.

Power BI can answer questions such as:

How has compliance changed?

Which policies have consistently caused problems?

Are non-compliance rates improving?

Which platforms are underperforming?

For real-time or near-real-time endpoint investigation, a different data source may be more appropriate.

Understanding the difference prevents a common reporting mistake: using a historical analytics source as though it were a live monitoring system.

Turning the Dashboard Into an Operational Tool

The best outcome is not a beautiful dashboard.

The best outcome is a dashboard that changes behavior.

Imagine an endpoint team beginning the week by opening the Power BI report.

The first page shows compliance has dropped from 94% to 90%.

The trend identifies that the decline started approximately one week earlier.

The policy view reveals that most failures involve one compliance requirement.

The platform analysis shows that the majority of affected devices are Windows endpoints.

The drill-through page identifies the specific devices.

The engineering team can now move from:

Data → Analysis → Investigation → Action

without manually exporting spreadsheets from the Intune portal.

That is the real value of combining Intune Data Warehouse with Power BI.

Example Dashboard Structure

A practical report could contain several pages.

The Executive Overview provides total devices, compliance percentage, compliant versus non-compliant devices, and the overall trend.

The Compliance Analysis page focuses on policy-level compliance, platform differences and the distribution of compliance states.

The Non-Compliance Analysis page identifies the most common causes, affected device groups and policies requiring attention.

The Device Detail page provides searchable device information for operational investigation.

The Trends & History page focuses on historical movement, allowing teams to identify improvement, deterioration and recurring patterns.

The exact number of pages is not important.

The logical flow is.

What the Dashboard Should Not Do

A compliance dashboard should not attempt to replace Intune.

Intune remains the endpoint management platform.

Power BI is the analytical layer.

The dashboard should therefore help people understand the environment rather than become another place where administrators attempt to manage devices.

This separation of responsibilities is healthy.

Intune manages.

The Data Warehouse preserves reporting-oriented information.

Power BI analyses.

The people operating the environment make decisions and take action.

Common Mistakes

One mistake is building visuals before understanding the Data Warehouse schema.

Another is calculating compliance without defining what "compliant" actually means.

Another is treating daily warehouse data as real-time information.

A further mistake is loading every available table simply because it is available.

And perhaps the most common mistake is building a dashboard for the person who created it instead of the person who needs to make decisions from it.

A dashboard should answer real questions.

If a visual does not help someone understand the environment or decide what to do next, it probably does not belong on the main page.

My Recommended Approach

I would approach an Intune Power BI project in four broad stages.

First, define the questions the dashboard must answer.

Second, understand the Intune Data Warehouse entities and relationships that can answer those questions.

Third, build a clean semantic model and reusable measures in Power BI.

Finally, design the report around the decisions the target audience needs to make.

This approach avoids a common trap where the project becomes:

"Let's import Intune data into Power BI and see what we can build."

Instead, it becomes:

"Let's solve a reporting problem using Intune data and Power BI."

That is a much stronger starting point.

Final Thoughts

Building compliance dashboards from the Intune Data Warehouse is a great example of how endpoint administration and data analytics can complement one another.

Intune already contains valuable information.

The challenge is making that information understandable.

The Data Warehouse provides the historical, structured foundation.

OData provides a standard access layer.

Power BI provides the modelling, calculations and visualization.

Together, they can create a reporting solution that helps security and endpoint teams move beyond static numbers and toward meaningful analysis.

The most important lesson is that a dashboard should not simply tell you what happened.

It should help you understand:

What happened?

Why did it happen?

Is it getting better or worse?

Where is the problem?

What should we do next?

That is where Power BI becomes more than a visualization tool.

It becomes a decision-support platform for endpoint security and management.

I remain learning, testing and improving my understanding of Microsoft Intune, Power BI and the broader Microsoft security ecosystem. Every dashboard, query and solution is another opportunity to turn technical data into something practical and useful.

We learn. We build. We improve.

Rolling Out LAPS in a Hybrid AD and Entra ID Environment

Songeziwe Fayindlala — Sun, 16 Aug 2026 00:20:40 +0000

Introduction

Local administrator accounts are one of those things that every Windows administrator needs, but few security teams are comfortable leaving unmanaged.

In many organizations, devices still contain powerful local accounts such as Administrator, admin, or a dedicated support account. When the same password is used across hundreds or thousands of machines, that convenience can quickly become a security problem. A compromised password on one workstation can become a stepping stone to other systems.

This is where Windows Local Administrator Password Solution, better known as Windows LAPS, comes in.

Windows LAPS is Microsoft's built-in capability for automatically managing local administrator passwords on supported Windows devices. It can generate and rotate passwords automatically, control how long passwords remain valid, and securely back up those credentials to either Windows Server Active Directory or Microsoft Entra ID.

For organizations running a hybrid identity environment, however, deploying LAPS is not simply a matter of switching on a policy. The real challenge is deciding where passwords should be stored, how administrators should retrieve them, how permissions should be controlled, and how the rollout should be introduced without disrupting support operations.

This article walks through that problem from an infrastructure and security perspective.

What Windows LAPS Actually Solves

The fundamental problem LAPS addresses is password reuse.

Imagine an organization with 1,000 Windows computers. Each computer has a local administrator account called Administrator, and all 1,000 machines use the same password.

That might make life easier for IT support, but from a security perspective it creates a large blast radius.

If an attacker obtains that password from one machine, the same credential may work on hundreds of others. The attacker does not necessarily need to compromise a domain administrator account. A local administrator credential can provide enough access to move laterally, deploy malware, disable security controls, dump credentials, or establish persistence.

LAPS changes this model.

Instead of maintaining one shared password, each device receives its own unique local administrator password. Windows LAPS automatically manages that password and periodically rotates it according to the policy configured by the organization.

The result is a much smaller security blast radius.

A compromised password becomes a problem for one machine rather than an organization-wide reusable credential.

That is the most important security benefit of LAPS.

Why Hybrid Environments Make LAPS More Interesting

A traditional Active Directory environment is relatively straightforward. Devices are domain joined, Group Policy is readily available, and administrators are accustomed to working with Active Directory as the source of identity and device information.

Modern enterprises are rarely that simple.

Many organizations now operate a hybrid environment where devices are joined to on-premises Active Directory while also being registered as Microsoft Entra hybrid joined devices. Intune may be managing endpoint policies while Active Directory continues to provide traditional domain services.

This creates an important architectural decision:

Where should the LAPS password be stored?

Microsoft supports Windows LAPS backups to either Windows Server Active Directory or Microsoft Entra ID. A hybrid-joined device can use either destination, but it cannot back up the same LAPS password to both at the same time.

That one design decision has consequences for administration, recovery, security and troubleshooting.

Understanding the Two Storage Models

Windows Server Active Directory as the LAPS Password Store

With the Active Directory model, the managed password is stored against the computer object in on-premises Active Directory.

This approach fits organizations that still rely heavily on traditional domain infrastructure and have their support processes built around Active Directory.

Administrators can use Windows LAPS PowerShell commands such as:

Get-LapsADPassword -Identity COMPUTERNAME -AsPlainText

Microsoft also provides specific PowerShell commands for configuring the required Active Directory permissions. For example, computer accounts need appropriate permissions to update their own LAPS information, while designated administrators or support groups should receive controlled password-read permissions.

The major advantage is operational familiarity.

Your existing infrastructure team can continue using Active Directory-based workflows, while access to passwords can be delegated to a dedicated security or help-desk group instead of giving everyone Domain Admin privileges.

This model is particularly attractive when machines must continue operating reliably in environments where on-premises Active Directory remains critical.

Microsoft Entra ID as the LAPS Password Store

The second model is to back up LAPS credentials to Microsoft Entra ID.

This is particularly useful for organizations moving toward cloud-managed endpoints and Microsoft Intune. Intune can configure Windows LAPS, rotate the password and provide an administrative interface for viewing password information where the administrator has sufficient permissions.

Microsoft also provides the Get-LapsAADPassword PowerShell cmdlet for retrieving credentials stored in Microsoft Entra ID.

For example:

Get-LapsAADPassword -Identity COMPUTERNAME

Microsoft Entra provides granular permissions for LAPS retrieval. A custom role can be granted permission to read LAPS metadata without necessarily giving it permission to retrieve the password itself. The password-reading permission is:

microsoft.directory/deviceLocalCredentials/password/read

while the metadata-only permission is:

microsoft.directory/deviceLocalCredentials/standard/read

This is important because the ability to see that a password exists is very different from the ability to retrieve the actual credential.

The Architecture I Would Use in a Hybrid Environment

There is no universal answer for every organization.

The correct design depends on where endpoint management is heading.

If an organization is heavily dependent on on-premises Active Directory, traditional domain support and on-premises administrative workflows, backing up LAPS passwords to Active Directory is a logical choice.

If the organization is moving toward Intune, Microsoft Entra ID and cloud-first endpoint management, using Microsoft Entra ID as the backup directory can provide a cleaner long-term architecture.

The important point is not to configure both.

A hybrid-joined device can back up its LAPS password either to Active Directory or Microsoft Entra ID, but not to both.

For a modern hybrid organization, I would make the decision based on the target operating model rather than simply copying the existing infrastructure.

If the long-term strategy is "Active Directory forever", AD-backed LAPS makes sense.

If the long-term strategy is "cloud-managed Windows endpoints", Entra-backed LAPS becomes more attractive.

LAPS Is More Than Password Rotation

One misconception about LAPS is that it simply changes the Administrator password every 30 days.

That is only part of the solution.

Windows LAPS supports password length, password complexity, password age and post-authentication actions. It can also manage the local account itself on supported newer Windows releases.

Post-authentication actions are particularly interesting.

An administrator might use the LAPS password to perform emergency maintenance on a device. After authentication, Windows LAPS can provide a defined grace period and subsequently reset the password. Depending on the configured policy, it can also sign out the account or restart the computer.

That means the security model becomes:

retrieve credential → perform required administrative task → credential becomes invalid again

rather than:

retrieve credential → continue using the same credential indefinitely

That is a much stronger approach.

A Practical Password Policy

A LAPS deployment should not be designed around the shortest possible password that passes a compliance check.

The password should be long enough to resist offline and automated attacks while remaining compatible with operational requirements.

Windows LAPS supports configurable password length, complexity and password age. It also supports passphrase-based configuration.

For example, an organization might decide that the local administrator password should rotate every 7 days, or use another interval based on its risk profile.

The exact value should not be copied blindly from another organization.

A highly restricted environment may choose a shorter rotation period.

A large enterprise with thousands of devices may prefer a longer interval combined with strong passwords and aggressive post-authentication controls.

The important point is to treat password lifetime as a risk decision rather than an arbitrary number.

The Account Itself Matters

Another area that deserves attention is the local administrator account.

Many organizations already have accounts named:

Administrator
admin
SupportAdmin
LocalAdmin

LAPS can manage a specified local administrator account. It can also support automatic account management on supported versions of Windows 11 and Windows Server, allowing organizations to simplify the management of the built-in account or a custom account.

This creates an opportunity to standardise endpoint administration instead of continuing to maintain several unmanaged local administrator accounts.

One important limitation is that Windows LAPS manages one local administrator account per device at a time. Changing the account targeted by the policy means the previous account is no longer managed by that LAPS policy.

That is something that should be considered before deployment.

Permissions Are More Important Than the Password

A technically correct LAPS deployment can still be insecure if too many people can retrieve the passwords.

This is where least privilege becomes critical.

An organization should not give the entire IT department unrestricted access to every local administrator password.

Instead, access should be delegated according to operational responsibility.

For example, a service desk team might have permission to retrieve passwords for workstation devices, while a server administration team might have access to server OUs.

With Active Directory-backed LAPS, Microsoft provides commands such as:

Set-LapsADReadPasswordPermission

to delegate password-query permissions to specific principals. Microsoft also distinguishes between reading the password and having the necessary permission to decrypt encrypted passwords stored in Active Directory.

The same principle applies in Microsoft Entra ID.

Microsoft Entra supports separate permissions for reading LAPS metadata and reading the actual password, which makes custom least-privilege administrative roles possible.

The password is valuable, but the ability to retrieve thousands of passwords is even more valuable to an attacker.

That permission therefore deserves the same level of attention as other privileged access.

Active Directory LAPS and Entra LAPS: The Security Comparison

From a security perspective, neither storage location should be treated as automatically "more secure" simply because it is cloud or on-premises.

The question is where the organization can enforce the strongest access controls and monitoring.

An Active Directory implementation can be strong when administrative access is tightly delegated, LAPS passwords are protected with the appropriate encryption controls, and the relevant OUs are carefully secured.

An Entra implementation can be strong when Microsoft Entra RBAC, Intune RBAC, privileged identity management, logging and conditional access controls are properly implemented.

The weak point is usually not the technology.

The weak point is excessive administrative access.

A LAPS password that is rotated every seven days but can be retrieved by dozens of unnecessary administrators is still a security problem.

Rolling LAPS Out Without Breaking the Environment

A large LAPS deployment should be treated as an infrastructure change, not simply an Intune policy.

The rollout should begin with discovery.

Before creating the production policy, determine which Windows versions are actually deployed, which devices are hybrid joined, which devices are Entra joined, which devices are domain joined, which local administrator accounts exist, which devices are already using legacy Microsoft LAPS, and which administrative teams currently depend on shared local passwords.

This discovery phase often reveals the real complexity.

For example, an organization may discover that some machines use Administrator, others use admin, and others have a custom support account.

Trying to deploy a single LAPS policy without understanding those differences is how migrations become messy.

Pilot Before Production

The next stage should be a controlled pilot.

A small group of test devices should receive the LAPS policy first.

The goal is not simply to verify that the password changes.

The goal is to verify the entire process.

The device should receive the policy, generate or set the password, successfully back up the credential to the selected directory, allow the correct support team to retrieve it, allow the administrator to use it, rotate the password, and record the appropriate events.

Windows LAPS processes policy periodically, and administrators can trigger policy processing with:

Invoke-LapsPolicyProcessing

This makes testing much easier because administrators do not always need to wait for the next processing cycle.

For an Active Directory deployment, administrators can verify successful updates through Windows LAPS events, including event ID 10018 for successful password updates to Active Directory.

For Microsoft Entra-backed deployments, event ID 10029 can be used to verify successful password backup activity.

The Production Rollout

Once the pilot is successful, rollout should happen in controlled waves.

A good production deployment is not "deploy to 5,000 machines and see what happens".

Instead, begin with a small production OU or Intune device group, review compliance and password-backup success, then expand to additional device groups.

This also makes troubleshooting easier.

If a deployment suddenly shows hundreds of failures, administrators need to be able to identify what changed between the successful and unsuccessful groups.

Phased rollout makes that possible.

What Happens When a Device Is Offline?

This is one of the practical questions that usually comes up during a hybrid LAPS deployment.

The answer depends on which backup directory and management mechanism are being used, as well as the device's connectivity.

A device does not need to be permanently connected to the corporate network simply because it uses LAPS. However, the device must be able to process its policy and successfully communicate with the directory used for password backup.

This is one of the reasons why the backup-directory decision should be made together with the endpoint connectivity and support model.

The architecture should reflect how users actually work, not how the environment looked five years ago.

Monitoring the Deployment

A LAPS deployment should be monitored like any other security control.

The important question is not simply:

"Is LAPS enabled?"

The better questions are:

"Are passwords rotating?"

"Are passwords being successfully backed up?"

"Who is retrieving them?"

"Are there devices that have stopped updating?"

"Are any devices still using unmanaged local administrator passwords?"

"Are administrators using the retrieved credentials for longer than necessary?"

Microsoft provides monitoring options through Intune, event logs, Active Directory attributes and PowerShell. Intune can also show password rotation information and device-level account details to administrators who have the required RBAC permissions.

This is where LAPS becomes part of the organization's broader identity and endpoint security strategy rather than just another configuration policy.

LAPS and Security Monitoring

LAPS should also be considered alongside Microsoft Defender, Microsoft Sentinel and endpoint logging.

A local administrator account suddenly being used on dozens of machines is suspicious.

A password retrieval event followed by privileged activity, remote connections or attempts to disable security tooling may deserve investigation.

The more mature approach is to combine LAPS with endpoint telemetry.

For example, LAPS can control the credential while Defender for Endpoint identifies suspicious activity performed using that credential.

Neither system replaces the other.

They work better together.

What About Legacy Microsoft LAPS?

Organizations that already use the older Microsoft LAPS implementation should plan a migration rather than running the legacy solution indefinitely.

Microsoft recommends migrating existing environments to Windows LAPS. Windows LAPS can coexist temporarily with legacy LAPS, but the policies need to target different local accounts for side-by-side operation.

Microsoft documents two main migration approaches.

The first is an immediate transition where the legacy policy is removed and Windows LAPS is introduced.

The second is a temporary side-by-side deployment using a different local account before the legacy configuration is eventually retired.

Whichever approach is chosen, the migration should be tested before the legacy deployment is removed from production.

Common Mistakes During a LAPS Deployment

The biggest mistake is treating LAPS as a password-change tool.

It is actually an identity security control.

Another common mistake is giving too many people permission to retrieve credentials.

A third is deploying the policy before identifying the actual local administrator accounts in the organization.

Another problem is failing to decide where passwords belong before deployment.

Hybrid environments make this especially important because Microsoft allows hybrid-joined devices to back up passwords to either Active Directory or Microsoft Entra ID, but not both.

A final mistake is failing to test the recovery process.

A password that rotates successfully but cannot be retrieved by the help desk is not a successful deployment.

My Recommended Hybrid Strategy

For an organization that is still heavily dependent on on-premises Active Directory, I would normally start with Active Directory-backed Windows LAPS, provided the organization can properly delegate password access and protect the relevant OUs.

For organizations that are already strongly invested in Intune and are deliberately moving toward cloud-managed endpoints, Microsoft Entra-backed LAPS is a compelling long-term architecture.

The important part is to make the decision based on the organisation's target state rather than its current state.

LAPS should form part of the migration toward stronger endpoint security, not become another legacy dependency.

A Simple Rollout Model

The deployment can be thought of as a sequence rather than a single change.

First, assess the current environment.

Then decide whether Active Directory or Microsoft Entra ID will be the authoritative LAPS password store.

Next, define the local account that LAPS will manage and design the password and rotation policy.

After that, configure the required permissions and test password retrieval.

The pilot should then validate the complete lifecycle from policy deployment to password rotation and administrative recovery.

Only after that should the organization expand the deployment into production in controlled waves.

Finally, monitoring should become part of normal security operations.

This approach dramatically reduces the risk of introducing an endpoint security policy without understanding its operational consequences.

The Bigger Security Picture

LAPS does not solve every local administrator problem.

It does something more specific and arguably more important: it removes the need for organizations to rely on shared, static local administrator passwords.

That single change can significantly reduce lateral-movement risk.

The real value of LAPS appears when it is combined with the rest of the Microsoft security stack.

Microsoft Entra ID provides identity and role-based access control.

Intune provides policy management.

Windows LAPS manages privileged local credentials.

Microsoft Defender provides endpoint visibility.

Microsoft Sentinel can provide broader security monitoring and correlation.

Together, these controls create a much stronger security architecture than any single product could provide.

Final Thoughts

Rolling out LAPS in a hybrid Active Directory and Microsoft Entra environment is not difficult because the technology is complicated.

It is difficult because the environment itself is complicated.

The organization has to make decisions about identity, endpoint management, administrative permissions, password storage, help-desk access, monitoring and migration.

Windows LAPS gives administrators the technology needed to solve the local administrator password problem.

The architecture and governance determine whether that technology becomes a real security improvement.

For organizations still using shared local administrator passwords, LAPS should not be viewed as an optional optimization.

It should be viewed as one of the foundational controls for securing Windows endpoints.

The goal is simple:

Every device should have a strong local administrator credential.

That credential should be unique.

It should rotate automatically.

Only authorized administrators should be able to retrieve it.

And the organization should know when and where that credential is being used.

That is the real value of Windows LAPS.