qPowerShell is one of the most powerful tools built into Windows.

It can:

• Manage files
• Query Windows
• Automate administration
• Control services
• Access APIs
• Work with .NET
• Query system information
• Automate enterprise environments
• Execute scripts

That flexibility is exactly what makes PowerShell so useful.

And exactly what makes it interesting to attackers.

But Windows and PowerShell have a mechanism that can significantly restrict what PowerShell code is allowed to do.

It’s called:

Constrained Language Mode

Instead of allowing PowerShell to use its full language and runtime capabilities, Constrained Language Mode — commonly abbreviated CLM — limits certain language features and operations.

Think of it as:

Full PowerShell
      ↓
Almost everything available

versus:

Constrained Language Mode
      ↓
PowerShell
+
Restrictions
+
Controlled capabilities

This doesn’t magically make a Windows computer secure.

It doesn’t stop every attack.

And it isn’t a replacement for application control, endpoint security, logging, or least privilege.

But understanding CLM gives security researchers an important insight into how Windows can restrict scripting capabilities.

What Is PowerShell Constrained Language Mode?

PowerShell has different language modes that determine which language features are available.

The main modes include:

FullLanguage
ConstrainedLanguage
RestrictedLanguage
NoLanguage

The most important for Windows security is:

ConstrainedLanguage

Microsoft documents Constrained Language as a mode intended to limit the capabilities available to PowerShell code, particularly when application-control policies such as WDAC are being used.

In simple terms:

CLM lets PowerShell continue doing useful administrative work while restricting some powerful language capabilities that could otherwise provide much broader access to the underlying .NET and Windows environment.

Why Does CLM Exist?

Imagine an organization where users legitimately need PowerShell.

For example:

IT Department
    ↓
PowerShell
    ↓
System administration

Completely disabling PowerShell would make administration harder.

But unrestricted scripting can provide a very powerful execution environment.

So the security objective becomes:

Allow useful PowerShell
        +
Reduce dangerous capabilities
        +
Enforce stronger application controls

That’s where Constrained Language Mode becomes useful.

Full Language vs Constrained Language

Consider normal PowerShell:

FullLanguage

It provides broad access to PowerShell’s language features.

CLM restricts some of those capabilities.

A simplified model is:

                    PowerShell
                        |
             ┌──────────┴──────────┐
             ↓                     ↓
       Full Language         Constrained Language
             |                     |
        Broad features        Restricted features
             |                     |
             ↓                     ↓
      More flexibility       Smaller attack surface

The exact restrictions are more nuanced than this diagram suggests.

How Do I Check My PowerShell Language Mode?

Run:

$ExecutionContext.SessionState.LanguageMode

On an unrestricted PowerShell session, you may see:

FullLanguage

If CLM is active:

ConstrainedLanguage

This is one of the simplest PowerShell security checks you can perform.

Try It on Your Own System

Open PowerShell and run:

$ExecutionContext.SessionState.LanguageMode

Then record the result.

For example:

FullLanguage

That doesn’t mean your computer is insecure.

It simply tells you the current PowerShell language mode.

Likewise:

ConstrainedLanguage

doesn’t automatically mean you’re under attack.

It may indicate that an application-control policy is enforcing restrictions.

What Does Constrained Language Actually Restrict?

This is where CLM gets interesting.

PowerShell can interact with the .NET runtime.

For example, in a normal FullLanguage environment, PowerShell can use .NET types through syntax such as:

[System.Environment]::MachineName

CLM places restrictions around certain uses of .NET types and methods.

The goal is to prevent PowerShell from simply becoming an unrestricted gateway into every underlying runtime capability.

Microsoft documents that Constrained Language restricts certain language elements, type conversions, method invocation, and access to .NET APIs.

Why .NET Matters

PowerShell isn’t just a command shell.

It’s deeply integrated with the .NET runtime.

That means PowerShell can interact with:

PowerShell
    ↓
.NET
    ↓
Windows APIs
    ↓
Operating System

This is extremely useful for legitimate administration.

But from a defensive perspective, it means unrestricted PowerShell can become a very capable execution environment.

CLM attempts to narrow that capability.

A Simple Example

In FullLanguage mode, PowerShell can access many .NET types.

For example:

[System.Environment]::OSVersion

This is simply asking .NET for operating-system information.

In a constrained environment, access to types and methods is subject to additional restrictions.

The important lesson isn’t memorizing which individual commands work.

It’s understanding:

PowerShell language mode changes the capabilities available to the script.

CLM Is Not “PowerShell Lite”

A common misconception is:

“Constrained Language Mode disables PowerShell.”

It doesn’t.

PowerShell can still perform many normal administrative operations.

For example:

Get-Process

or:

Get-Service

may still be useful.

The goal isn’t:

PowerShell = OFF

The goal is:

PowerShell = CONTROLLED

Where CLM Becomes Especially Important

CLM is most meaningful when combined with application control.

Microsoft’s documentation explains that on Windows, Constrained Language Mode is normally enforced automatically when a system is under a policy such as Windows Defender Application Control (WDAC), rather than being something administrators should simply treat as a standalone security switch.

This distinction is extremely important.

You shouldn’t think:

"I'll just set CLM and everything is protected."

Think:

Application Control
       ↓
PowerShell Policy
       ↓
Constrained Language Mode
       ↓
Reduced scripting capability

WDAC and CLM

Windows Defender Application Control, now generally referred to as App Control for Business, is Microsoft’s application-control technology for controlling which code is allowed to run.

Microsoft documents that PowerShell can detect application-control policy and use Constrained Language Mode when appropriate.

Conceptually:

Application Control
       |
       ↓
Which code is trusted?
       |
       ↓
PowerShell policy
       |
       ↓
Language restrictions

This is much stronger than simply telling users:

“Please don’t run dangerous scripts.”

Why Application Control Matters

Traditional security often asks:

“Can antivirus detect this?”

Application control asks a different question:

“Should this code be allowed to execute at all?”

That is a fundamentally different security model.

Instead of relying exclusively on detection:

Unknown Code
     ↓
Detect
     ↓
Maybe block

application control attempts to establish:

Code
 ↓
Policy
 ↓
Allowed?
 ├── Yes
 └── No

CLM Is About Reducing Attack Surface

Suppose an attacker somehow gets access to a PowerShell execution environment.

If that environment is completely unrestricted:

PowerShell
    ↓
.NET
    ↓
Extensive system capabilities

With appropriate application-control enforcement:

PowerShell
    ↓
Constrained Language Mode
    ↓
Restricted language capabilities

This doesn’t eliminate the attack.

But it can reduce what the attacker can accomplish through that particular mechanism.

Important: CLM Is Not a Sandbox

This distinction deserves emphasis.

Constrained Language Mode is not a complete security sandbox.

It doesn’t mean:

Attacker
   ↓
CLM
   ↓
Nothing else works

Windows security is layered.

A realistic security architecture looks more like:

Identity
   +
MFA
   +
Least Privilege
   +
Application Control
   +
PowerShell Controls
   +
EDR
   +
Logging
   +
Network Controls
   +
Backups

CLM is one layer.

Can Administrators Use CLM?

Yes, but the implementation matters.

In enterprise environments, administrators should understand how PowerShell language mode is being enforced and how it interacts with application-control policy.

You should avoid treating this as a simple:

$ExecutionContext.SessionState.LanguageMode = ...

configuration exercise.

Why?

Because changing the current session’s language mode isn’t equivalent to deploying a security boundary.

A real enterprise control should be enforced through the appropriate Windows application-control architecture.

The Difference Between Policy and Session State

This is a subtle but important concept.

You can inspect:

$ExecutionContext.SessionState.LanguageMode

and see:

ConstrainedLanguage

But that doesn’t tell you everything about why the session is constrained.

The security architecture matters.

You should determine:

What policy is enforcing this?

rather than assuming:

Someone manually changed the session.

Why Attackers Care About PowerShell Restrictions

Attackers often want flexible scripting environments.

PowerShell can provide:

• System discovery
• Automation
• Process interaction
• File operations
• Network operations
• Administrative functionality

Therefore, defenders shouldn’t focus only on blocking a handful of PowerShell commands.

Instead, they should consider:

Who can execute PowerShell?
       ↓
Under what policy?
       ↓
With what language mode?
       ↓
What scripts are trusted?
       ↓
What actions are logged?

PowerShell Logging Still Matters

Even with CLM, logging is extremely important.

PowerShell supports several logging mechanisms, including:

• Script Block Logging
• Module Logging
• Transcription

Microsoft documents these logging capabilities as part of PowerShell’s security and auditing features.

The idea is simple:

PowerShell activity
       ↓
Telemetry
       ↓
Detection
       ↓
Investigation

Script Block Logging

Script Block Logging can record PowerShell script content and related activity in Windows event logs when configured.

This is useful because attackers may try to hide behind legitimate PowerShell.

Instead of seeing:

powershell.exe

and stopping there, defenders can potentially inspect the script content and correlate it with:

User
Process
Host
Time
Network
Other events

Microsoft documents PowerShell Script Block Logging and its configuration options.

Module Logging

PowerShell can also provide module-level telemetry.

This can help defenders understand which PowerShell modules are being used.

For example:

PowerShell
    ↓
Module
    ↓
Command

That provides more context than simply seeing the PowerShell executable.

PowerShell Transcription

PowerShell transcription can record interactive PowerShell sessions.

Conceptually:

User
 ↓
PowerShell
 ↓
Transcript
 ↓
Log storage

This can be useful for administrative auditing and incident response.

However, logs need appropriate protection.

If an attacker compromises a machine and can freely alter or delete the only local logs, your evidence becomes much less reliable.

Centralized Logging Is Better

A stronger architecture is:

Endpoint
   ↓
PowerShell logs
   ↓
Central collector
   ↓
SIEM
   ↓
Detection

This reduces dependence on a single compromised machine.

A PowerShell Security Lab

You can safely investigate language modes without running malicious code.

Open PowerShell and run:

$ExecutionContext.SessionState.LanguageMode

Then:

$PSVersionTable

This tells you what PowerShell environment you’re using.

Then inspect your current policy-related environment.

You can also check whether application-control events are present in the Windows Event Viewer on a system where such policies are deployed.

Lab: Compare PowerShell Capabilities

Create two controlled environments if you have access to them:

Windows VM A
FullLanguage
Windows VM B
ConstrainedLanguage

Then test harmless operations.

For example:

Get-Process

Get-Service

Get-ComputerInfo

And compare the behavior.

The goal isn’t to find a way around restrictions.

The goal is to understand:

Which capabilities change when the language mode changes?

⚠️ Use This Only in Your Own Lab

Do not experiment with PowerShell restrictions on production systems without understanding the consequences.

In particular:

• Don’t randomly change WDAC policies.
• Don’t disable endpoint security.
• Don’t modify enterprise PowerShell policies without authorization.
• Don’t attempt to bypass CLM on systems you don’t own.
• Don’t test evasion techniques against third-party systems.

A Windows VM is enough to learn the fundamentals.

How to Investigate CLM During Incident Response

Suppose you investigate a Windows endpoint and discover:

PowerShell
+
ConstrainedLanguage

Don’t immediately conclude:

“This computer was hacked.”

Instead determine:

1. Why is CLM active?

Is application control enforcing it?

2. Which user is running PowerShell?

User

3. Which process launched it?

Parent process

4. What script was executed?

Use available PowerShell logging.

5. What happened afterward?

Check:

Process creation
Files
Registry
Network
Authentication

Parent Process Matters

Imagine:

explorer.exe
    ↓
powershell.exe

That can happen during normal user activity.

Now compare:

UnknownApplication.exe
    ↓
powershell.exe

This deserves investigation.

And:

Office application
    ↓
powershell.exe

may also warrant investigation depending on context.

The key is:

PowerShell itself is not the complete story.

CLM + Process Telemetry

A useful investigation chain is:

Process
  ↓
PowerShell
  ↓
Language Mode
  ↓
Script
  ↓
Child Processes
  ↓
Files
  ↓
Network

This gives analysts a behavioral picture.

CLM + EDR

Modern endpoint security can correlate:

PowerShell execution
+
User
+
Parent process
+
Command line
+
Script content
+
Network activity
+
File changes

This is far more useful than simply blocking powershell.exe.

Why?

Because PowerShell is a legitimate administrative tool.

Blocking it entirely can break legitimate workflows.

Why Blocking PowerShell Completely Isn’t Always Practical

Many organizations rely on PowerShell.

Administrators use it for:

• Microsoft 365 management
• Active Directory
• Windows administration
• Cloud management
• Automation
• Configuration
• Monitoring

Therefore:

Block PowerShell

isn’t always realistic.

A better security model can be:

PowerShell
   ↓
Authentication
   ↓
Application Control
   ↓
Language Restrictions
   ↓
Logging
   ↓
Monitoring

What About PowerShell 5.1 vs PowerShell 7?

This is another important detail.

Windows commonly includes Windows PowerShell 5.1.

PowerShell 7 is a newer, separately installed, cross-platform PowerShell implementation.

You can check your version with:

$PSVersionTable.PSVersion

The exact security behavior and management architecture can differ between versions.

So when documenting a security policy, don’t simply write:

“PowerShell.”

Specify:

Windows PowerShell 5.1

or:

PowerShell 7

where relevant.

CLM and PowerShell 7

PowerShell 7 supports language modes as well, but enterprise enforcement and application-control integration can differ from Windows PowerShell 5.1.

This is another reason to test security controls in the exact environment you’re deploying.

Don’t assume:

PowerShell 5.1 behavior
=
PowerShell 7 behavior

Common Misconceptions

Myth #1: CLM Blocks PowerShell

False.

CLM restricts certain capabilities.

PowerShell can remain useful for many administrative tasks.

Myth #2: CLM Stops Malware

Not by itself.

It is one security layer.

A determined attacker may have other execution paths or may already possess significant privileges.

Myth #3: Setting the LanguageMode Variable Is Enterprise Security

Not necessarily.

A session-level configuration is not the same as a policy-enforced security boundary.

Myth #4: FullLanguage Means You’re Insecure

False.

FullLanguage is normal on many Windows systems.

Security depends on the overall environment.

Myth #5: ConstrainedLanguage Means the System Is Compromised

Also false.

CLM can be intentionally enforced as part of an application-control policy.

CLM vs Application Control

These are related but different.

Think:

Application Control
        ↓
Execution Policy
        ↓
PowerShell
        ↓
Constrained Language

rather than treating them as competing technologies.

A Defender’s PowerShell Checklist

PowerShell Configuration

• What PowerShell version is installed?
• What language mode is active?
• Is application control deployed?
• Is CLM being enforced by policy?

Logging

• Is Script Block Logging enabled?
• Is Module Logging configured?
• Is transcription useful for the environment?
• Are logs centrally collected?

Identity

• Which users can execute PowerShell?
• Which accounts have administrative privileges?
• Are privileged accounts separated?

Process Monitoring

• Which applications launch PowerShell?
• Are unexpected parent processes detected?
• Are suspicious child processes monitored?

Network

• Are unusual outbound connections correlated with PowerShell?
• Are PowerShell processes making unexpected network requests?

What a Strong Detection Strategy Looks Like

Don’t build a rule saying:

IF powershell.exe
THEN ALERT

That would generate enormous noise.

Instead:

PowerShell
+
Unexpected Parent
+
Suspicious Command Line
+
Unusual User
+
Network Activity

Or:

PowerShell
+
Constrained Environment
+
Unexpected Child Process
+
File Modification

Or:

PowerShell
+
New Persistence Mechanism
+
Unusual Account

This is behavioral detection.

A Practical Threat-Hunting Example

Imagine a workstation generates:

10:15
User launches Office application
10:16
Office launches PowerShell
10:16
PowerShell executes a script
10:17
PowerShell launches another executable
10:17
Executable creates a scheduled task
10:18
Executable makes an outbound network connection

No individual event necessarily tells the whole story.

But together:

Office
 ↓
PowerShell
 ↓
Script
 ↓
Executable
 ↓
Persistence
 ↓
Network

creates a strong reason for investigation.

This is why modern security operations rely heavily on correlation.

Why CLM Is Interesting for Ethical Hackers

If you’re learning Windows security, don’t study CLM simply as:

“How do I bypass it?”

That’s a narrow way to approach the technology.

A better approach is:

Understand the intended security boundary.

Then ask:

What does the policy restrict?
Why?
What telemetry records it?
What applications still work?
What administrative workflows break?

Then, in a controlled lab, study where the boundary is strong and where administrators need additional controls.

This teaches you much more about Windows security architecture.

Blue Team Exercise

Create a small Windows security lab.

Windows VM
     |
     ├── PowerShell
     ├── Sysmon
     ├── Event Viewer
     └── Application Control

Your exercise:

Phase 1

Determine the default PowerShell language mode.

$ExecutionContext.SessionState.LanguageMode

Phase 2

Record PowerShell version:

$PSVersionTable.PSVersion

Phase 3

Enable appropriate PowerShell auditing in the lab.

Phase 4

Run harmless administrative commands.

Phase 5

Review the resulting telemetry.

Phase 6

Compare behavior when application-control policies are applied.

Your goal:

PowerShell action
      ↓
Policy
      ↓
Language mode
      ↓
Telemetry

That’s a real defensive exercise.

How Organizations Can Reduce PowerShell Risk

1. Use Application Control

Control which applications and scripts are trusted.

2. Use Least Privilege

Users shouldn’t have unnecessary administrative rights.

3. Enable PowerShell Logging

Collect useful telemetry.

4. Centralize Logs

Don’t rely entirely on the local endpoint.

5. Monitor Parent-Child Relationships

Know which applications are launching PowerShell.

6. Monitor Network Activity

PowerShell plus unusual outbound communication can be a useful detection signal.

7. Separate Administrative Accounts

Don’t use highly privileged identities for ordinary browsing and daily work.

8. Regularly Test Policies

Security controls should be validated against legitimate workflows before broad deployment.

The Bigger Lesson

PowerShell is not inherently malicious.

Neither is:

cmd.exe
WMI
Task Scheduler
Windows Services
.NET

All of these are legitimate technologies.

The security problem appears when powerful functionality is used outside the expected trust model.

That’s why modern security isn’t simply:

Good Tool
vs
Bad Tool

It’s:

Who
+
What
+
When
+
Where
+
Why
+
Under Which Policy

Frequently Asked Questions

What is PowerShell Constrained Language Mode?

Constrained Language Mode is a PowerShell language mode that restricts certain language features and access to some .NET functionality. It is primarily designed to reduce the capabilities available to scripts in controlled security environments.

How do I check my PowerShell language mode?

Run:

$ExecutionContext.SessionState.LanguageMode

Does Constrained Language Mode block PowerShell?

No.

It restricts certain capabilities while allowing many normal PowerShell operations to continue.

Is CLM an antivirus?

No.

It is a PowerShell security control, not an antivirus or EDR solution.

Is CLM a sandbox?

No.

It should be treated as one layer within a broader Windows security architecture.

What normally enforces CLM on Windows?

Microsoft documents application-control technologies such as WDAC/App Control as the mechanism used to enforce Constrained Language Mode in supported Windows configurations.

Does CLM stop every PowerShell attack?

No.

No individual security control should be treated as a complete defense.

Use:

Application Control
+
Least Privilege
+
Logging
+
EDR
+
Network Monitoring
+
Identity Security

for layered protection.

How do I check my PowerShell version?

Run:

$PSVersionTable.PSVersion

Why is PowerShell logging important?

Because seeing powershell.exe alone provides limited context. Script Block Logging, Module Logging, and transcription can provide additional information useful for detection and incident response.

Final Thoughts

PowerShell is one of the most powerful administrative technologies built into the Windows ecosystem.

Trying to eliminate it isn’t always realistic.

The better question is:

How can we keep PowerShell useful while reducing the amount of damage an attacker can do with it?

That’s where Constrained Language Mode becomes interesting.

The security architecture can look like:

                WINDOWS
                   |
          Application Control
                   |
                   ↓
             PowerShell
                   |
          Constrained Language
                   |
                   ↓
              Logging
                   |
                   ↓
             EDR / SIEM
                   |
                   ↓
              Detection

No single layer is perfect.

But layers reinforce each other.

And that’s the real lesson:

Security isn’t about making one tool impossible to abuse. It’s about making the entire attack chain harder to execute, easier to detect, and easier to investigate.

Learn what PowerShell can do.

Learn what CLM restricts.

Understand how application control enforces it.

Study the telemetry.

Then build your own Windows lab and observe the difference.

Because when you understand the operating system’s security boundaries, you stop merely memorizing commands.

You start understanding why Windows security works the way it does.

Think Like an Attacker. Investigate Like a Defender. Secure Like a Pro.