What is IT AMC in the USA and why do businesses need it?

IT AMC (Annual Maintenance Contract) in the USA is a comprehensive service agreement for maintaining all IT equipment and systems. Businesses need IT AMC for predictable costs, 24/7 support, preventive maintenance, reduced downtime, and expert technical assistance. It's the most affordable way to ensure reliable IT operations.

How much does IT AMC cost in the USA?

IT AMC pricing in the United States is scoped per engagement and depends on the number of devices, support level, and services included. Small businesses with basic coverage sit at the entry level, and comprehensive packages scale with the size of your estate. We offer the best affordable IT AMC solutions in United States with customized pricing.

What is included in managed IT services in the USA?

Our managed IT services in the USA include complete IT infrastructure management, 24/7 monitoring and support, cybersecurity, cloud services, backup and disaster recovery, help desk support, network management, and proactive maintenance. It's a complete IT department solution with affordable monthly pricing.

What is the response time for IT support in the USA?

GR IT Services responds to P1 critical issues in 5 minutes for managed clients, delivered remotely. We offer 24/7 reliable IT support to businesses across the USA with a guaranteed SLA.

Which areas in the USA does GR IT Services cover?

We provide IT support and managed IT services across all major USA cities including New York, Los Angeles, Chicago, Houston, Phoenix, Philadelphia, San Antonio, San Diego, Dallas, and San Jose. We serve businesses nationwide with complete IT support.

Why is GR IT Services the best IT company in the USA?

GR IT Services combines reliable 24/7 support, a 5-minute P1 response SLA, complete IT solutions, and certified Microsoft CSP and Apple Jamf partner status. We provide IT AMC and managed IT services across the USA with a guaranteed SLA and senior engineers on every engagement.

App Control for Business

Antivirus blocks what it recognizes as bad. Application control runs only what you said was good.

Microsoft puts the shift precisely: Windows stops being a place where everything executes unless the antivirus is confident it is malicious, and becomes a place where nothing executes unless your policy permitted it. That is the strongest control available on an endpoint, and it is the one most organizations look at once and quietly set aside.

Book an application control assessment See what it covers

Windows endpoints governed by an application control policy

Policy firstCode runs only if policy allows it
Beyond appsScripts, MSI, batch files and PowerShell
All editionsPro, Enterprise, Pro Education and Education
48 hoursBefore Smart App Control switches itself off

What application control does

Eight things worth knowing before the first policy is written.

This control is simultaneously the most effective thing you can do to an endpoint and the most likely to interrupt somebody mid-task. Nearly all of that risk is manageable, and it gets managed by knowing how far the control reaches and by running it in audit long before you enforce anything.

The inversion at the center of it

The default flips. Instead of everything executing unless your antivirus is confident something is malicious, nothing executes unless your policy already permitted it. That reversal is what defeats malware nobody has seen before, and it is also why the work depends on a genuine inventory of what your business runs rather than a list somebody assembled from memory.

It reaches well beyond applications

The scope takes in scripts and Microsoft installers, command-line batch files, and interactive Windows PowerShell sessions, which are held to Constrained Language Mode. That last behavior earns its place independently, since it forecloses one of the most heavily used routes for living-off-the-land intrusion techniques.

It sits alongside antivirus, not instead of it

Microsoft states this without hedging: application control hardens a machine substantially but does not replace antivirus, and an active antivirus product should stay in place beside it. The two answer different questions. One asks whether this thing is known to be harmful; the other asks whether anybody ever approved it.

Two technologies, and the choice matters

Windows carries both App Control for Business and AppLocker, and the choice between them is framed around your particular scenarios and requirements. Some App Control capabilities exist only on specific Windows versions, so what your fleet is actually running tends to settle the question faster than any feature comparison.

Smart App Control as the starting point

Available from Windows 11 version 22H2, Smart App Control permits signed code and code the cloud service predicts to be safe. Because it is built entirely on App Control for Business, its policy makes a sound foundation for one of your own, extended to trust the line-of-business software your company depends on.

The 48-hour behavior on managed devices

Smart App Control opens in evaluation mode and turns itself off inside 48 hours on enterprise managed devices unless the user switched it on first. That is worth confirming before anybody reports it as fleet-wide protection, because on managed hardware it is usually doing nothing at all.

The Intelligent Security Graph option

The same reputation service behind Smart App Control is available inside App Control for Business as the Intelligent Security Graph. Switching it on makes a policy far easier to live with across a varied fleet, and the price is that you are trusting a reputation judgment where you would otherwise have written an explicit rule.

Licensing that is unusually inclusive

Support spans Windows Pro, Enterprise, Pro Education, SE and Education, with entitlements running from Windows Pro through Enterprise E5 and Education A5. For a control operating at this level of strength, licensing is remarkably rarely the thing standing in the way.

The expected behavior that looks like a fault

Switching the reputation service on moves Defender Antivirus to passive mode. Nothing is broken.

This is documented plainly, and knowing it in advance heads off a support ticket that would otherwise be logged as a broken configuration.

Turn on Smart App Control, or enable App Control with the Intelligent Security Graph, and Microsoft Defender Antivirus moves to passive or hybrid mode on any machine using a non-Microsoft antivirus for real-time protection. That is documented as expected behavior rather than a bug or a sign that something was set up wrongly.
In that state Defender Antivirus performs the reputation checks App Control or Smart App Control depends on, while your chosen antivirus continues handling real-time protection. Both products are present and neither is redundant, which is a genuine exception to the usual rule about running a single antivirus.
The second surprise concerns managed hardware. Smart App Control begins in evaluation mode and disables itself within 48 hours on enterprise managed devices unless the user enabled it first, so any assumption that it is quietly protecting the fleet is usually wrong.
Switching it off deliberately means setting VerifiedAndReputablePolicyState under the CI Policy key, where 0 is off, 1 is enforce and 2 is evaluation, then running CiTool.exe with the refresh switch to make the change take effect. A deliberate off is a better position than an ambiguous one.

Ask us to assess your fleet

How we approach it

Four things that keep this project from being abandoned.

Abandonment rates here are high, and the postmortem reads the same way nearly every time: enforcement arrived before the audit phase had finished doing its job.

We run audit mode for longer than feels necessary

Audit records what the policy would have stopped without stopping anything. The point is to surface software that never made it into the inventory: the macro finance runs once a quarter, the tool a single engineering team depends on, the installer somebody keeps on a share. Every one of those appears in an audit log and none of them appear in a survey.

We plan for scripts, not just applications

Coverage extends across scripts, Microsoft installers, batch files and interactive PowerShell sessions running under Constrained Language Mode. Teams that scoped their inventory around installed programs and forgot everything else meet all of it at once on the morning enforcement begins.

We decide the reputation question explicitly

Enabling the Intelligent Security Graph makes a policy dramatically more workable across a varied fleet, because code you never explicitly allowed can still run on the strength of its cloud reputation. That is a real security trade, and it deserves a recorded decision with reasoning attached rather than a checkbox somebody ticked in passing.

We build the onboarding route before enforcing

The moment code only runs with policy approval, every new application needs a documented way of getting that approval. Without one, people invent workarounds, and workarounds are how a genuinely strong control decays into a weak one. The process is as much of a deliverable as the policy itself.

How a deployment runs

Four phases across roughly three to four months.

That is a longer schedule than most endpoint work, by design. Application control fails when enforcement lands before anybody understands the fleet, and understanding the fleet is precisely what the audit phase produces.

01
Month 1
Understand what actually runs
An application inventory spanning the fleet, deliberately including what nobody counts: engineering utilities, finance macros, scripts a department wrote for itself, installers people launch from a network share. Since the control reaches scripts and batch files, the inventory has to reach there too.
- Application inventory across representative device groups
- Signed and unsigned software separated
- Script and macro usage identified
- Device groups defined by application profile
02
Month 2
Author policy and run it in audit
A base policy written, optionally starting from the Smart App Control example policy with the conditional Windows lockdown option stripped out, then deployed in audit so it records everything it would have stopped while stopping nothing.
- Base policy authored with a documented rationale
- Intelligent Security Graph decision recorded
- Audit deployment across pilot groups
- Would-have-blocked events collected and triaged
03
Month 3
Refine until audit is quiet
Successive passes over the policy until legitimate software stops appearing in the audit log. Organizations shorten this phase under pressure, and it is the phase that decides whether enforcement day passes unnoticed. A noisy log going into enforcement means a queue of blocked users coming out of it.
- Policy refined against audit findings
- Line-of-business applications explicitly handled
- Exception process defined with owners
- Audit noise reduced to an agreed threshold
04
Month 4
Enforce progressively and operate
Enforcement introduced one device group at a time rather than everywhere at once, with a rollback route and a support path ready. Then the standing work: every new application needs a way into policy, or people will find a way around the control instead.
- Enforcement rolled out by device group
- Rollback path tested before broad enforcement
- New application onboarding process established
- Antivirus confirmed as still active alongside

Where this applies

Six situations where application control is proportionate.

It fits places where the software set is knowable and predictability outranks flexibility, and that describes a good deal more of a typical fleet than people expect going in.

An operator with fixed-function workstations

Plant terminals, control room machines and kiosks run a short, stable software list and have no business running anything outside it. This is the least difficult application control case there is, and it is routinely the one nobody has done, because attention went to the office fleet instead.

A regulated firm asked about executable control

Government and security organizations, the Australian Signals Directorate among them, repeatedly cite application control as one of the most effective answers to executable file-based malware, and allowlisting questions now appear on insurance questionnaires and in CMMC and NIST 800-171 aligned assessments. Having it enforced where it matters converts a hedged answer into a straight one.

A business that has had a ransomware scare

Ransomware depends on running code the endpoint has never encountered. A policy under which nothing executes without prior approval meets that head-on, in a way signature and behavioral detection cannot fully replicate. Of all the available controls, it is the one most likely to have changed how the story ended.

A provider with clinical systems on fixed builds

Clinical and diagnostic workstations run validated software that changes rarely, which is exactly the profile this control was built for. It also shields builds that cannot be patched quickly, since nothing unauthorized gets to execute on them in the first place.

An organization with a small privileged administrator group

Administrative workstations combine the highest value to an attacker with the smallest headcount, which makes them the obvious first deployment. A tightly drawn policy across a handful of machines returns disproportionate benefit and gives the team real operating experience before anything wider is attempted.

A company reducing reliance on detection alone

Where the entire strategy rests on detection, every improvement still depends on something being recognized as malicious first. Application control contributes a layer that never has to recognize anything, which is a different category of defense rather than more of what you already have.

Three positions

How US organizations control what executes.

Most fleets occupy the right-hand column, which is a defensible position carrying one specific hole: anything nobody has yet classified as malicious executes freely.

Unknown code blocked

Application control enforcedYes

Audit mode onlyLogged only

Antivirus and ASR rulesOnly if detected

Unsigned software controlled

Application control enforcedYes

Audit mode onlyVisible

Antivirus and ASR rulesNo

Scripts and batch files covered

Application control enforcedYes

Audit mode onlyVisible

Antivirus and ASR rulesPartly via ASR

PowerShell constrained

Application control enforcedConstrained Language Mode

Audit mode onlyNo

Antivirus and ASR rulesNo

Application inventory accurate

Application control enforcedNecessarily

Audit mode onlyYes

Antivirus and ASR rulesFrequently not

Effort to maintain

Application control enforcedOngoing

Audit mode onlyLow

Antivirus and ASR rulesLow

Risk of blocking legitimate work

Application control enforcedManaged by audit phase

Audit mode onlyNone

Antivirus and ASR rulesNone

Antivirus still required

Application control enforcedYes

Audit mode onlyYes

Antivirus and ASR rulesYes

New software needs a process

Application control enforcedYes

Audit mode onlyNo

Antivirus and ASR rulesNo

Effectiveness against novel malware

Application control enforcedHigh

Audit mode onlyNone

Antivirus and ASR rulesVariable

Feature	Application control enforced	Audit mode only	Antivirus and ASR rules
Unknown code blocked	Yes	Logged only	Only if detected
Unsigned software controlled	Yes	Visible	No
Scripts and batch files covered	Yes	Visible	Partly via ASR
PowerShell constrained	Constrained Language Mode	No	No
Application inventory accurate	Necessarily	Yes	Frequently not
Effort to maintain	Ongoing	Low	Low
Risk of blocking legitimate work	Managed by audit phase	None	None
Antivirus still required	Yes	Yes	Yes
New software needs a process	Yes	No	No
Effectiveness against novel malware	High	None	Variable

What gets controlled

Ten kinds of code, and whether this control governs each one.

Reaching past executables is what makes this control effective against contemporary intrusion technique, and it is equally what makes an audit phase non-negotiable.

Code path

Executables

Covered: Yes, the core case

Code path

DLLs and code in the system core

Covered: Yes, kernel mode code included

Code path

Microsoft installers, MSI

Covered: Yes

Code path

Scripts

Covered: Yes

Code path

Command-line batch files

Covered: Yes

Code path

Interactive PowerShell sessions

Covered: Yes, held to Constrained Language Mode

Code path

Unsigned line-of-business applications

Covered: Only where your policy permits them

Code path

Code with good cloud reputation

Covered: Only with the Intelligent Security Graph enabled

Code path

Known malware

Covered: Blocked, and unknown code is blocked too

Code path

Antivirus role

Covered: Still required alongside

Code path	Covered
Executables	Yes, the core case
DLLs and code in the system core	Yes, kernel mode code included
Microsoft installers, MSI	Yes
Scripts	Yes
Command-line batch files	Yes
Interactive PowerShell sessions	Yes, held to Constrained Language Mode
Unsigned line-of-business applications	Only where your policy permits them
Code with good cloud reputation	Only with the Intelligent Security Graph enabled
Known malware	Blocked, and unknown code is blocked too
Antivirus role	Still required alongside

How an engagement runs

Five steps, and the third is where the time goes.

Inventory, author, audit, refine, enforce. Whether enforcement day is quiet comes down to the refine loop, and no amount of wanting it to be shorter makes it shorter.

1
Inventory what runs, including scripts
Applications, installers, scripts, batch files and macros across representative device groups, with signed and unsigned software separated out. Because coverage extends to all of those, an inventory limited to installed programs is incomplete before the work has even started.
2
Choose the technology and the trust model
App Control for Business or AppLocker, and whether the Intelligent Security Graph is enabled so cloud reputation can vouch for code you never explicitly allowed. Both decisions get recorded with the reasoning behind them, because everything downstream is shaped by them.
3
Author and deploy in audit mode
A base policy, optionally derived from the Smart App Control example policy with the conditional Windows lockdown option removed as the documentation requires. It goes out in audit, recording everything it would have stopped while stopping nothing at all.
4
Refine until the audit log is quiet
Repeated passes against real would-have-blocked events until legitimate software no longer shows up. This is the phase that gets compressed whenever a deadline appears, and it is the phase that determines whether enforcement causes an incident.
5
Enforce progressively and build the onboarding route
Group by group, with a tested rollback, antivirus verified as still running alongside, and a defined path for admitting new software into policy. Without that path the control degrades, because people route around whatever stands between them and their work.

Straight answers

What organizations ask about application control.

Antivirus asks whether something is known to be harmful. Application control asks whether anybody permitted it. Microsoft frames the change as Windows moving from a place where all code runs unless the antivirus confidently predicts it is bad, to a place where code runs only if your policy says so.

No, and the documentation says so directly. Application control hardens machines substantially against malicious code without being a replacement for antivirus, and an active antivirus product should remain in place beside it. The two cover different failure modes and neither substitutes for the other.

It does. Coverage runs past applications into scripts and Microsoft installers, command-line batch files, and interactive Windows PowerShell sessions, which execute under Constrained Language Mode. That PowerShell constraint is one of the more valuable things you inherit by adopting the control at all.

No. Windows Pro, Enterprise, Pro Education, SE and Education all support App Control for Business, with entitlements granted from Windows Pro through Enterprise E3 and E5 and Education A3 and A5. For a control of this strength, licensing is very seldom what blocks adoption.

The choice is framed around your specific scenarios and requirements, with the note that certain App Control for Business capabilities appear only on particular Windows versions. In practice the makeup of your fleet and the Windows versions inside it answer the question before a feature comparison does.

Most likely not. It opens in evaluation mode and disables itself within 48 hours on enterprise managed devices unless the user turned it on first. Organizations assuming it delivers fleet-wide protection are generally mistaken, and it takes very little effort to verify rather than assume.

Yes. Windows carries the example policy under its CodeIntegrity example policies. One step is mandatory before you use it: remove the Enabled Conditional Windows Lockdown Policy option so the file is valid as an App Control for Business policy. From there you extend it to trust your own line-of-business software.

Because Smart App Control was turned on, or App Control was enabled with the Intelligent Security Graph, on a machine running a non-Microsoft antivirus for real-time protection. This is documented as expected behavior rather than a bug or a misconfiguration. Defender handles the reputation checks while your antivirus keeps real-time protection.

It is the same reputation service Smart App Control relies on, exposed inside App Control for Business. Enabling it makes a policy far easier to operate across a varied fleet by extending trust to code with good reputation. That is a genuine security trade, so it belongs in the design record as a decision rather than arriving as a default.

Long enough to cover a complete cycle of business activity, which in practice means a month at minimum. The objective is to catch the software nobody mentioned: quarterly processes, departmental scripts, the tool one team cannot work without. None of it shows up in a survey and all of it shows up in audit.

Legitimate work stops, the security team drowns in exception requests, and the program is usually shelved. That sequence is the most common ending for an application control effort, and it follows almost entirely from cutting the audit phase short.

Administrative workstations, or fixed-function machines. Both run short, stable software lists and carry outsized value, and both give the team genuine operational experience inside a blast radius you can manage before anything touches the general office fleet.

They need a defined route into policy, and building it before enforcement begins is essential rather than optional. Without one, people find workarounds, and workarounds are how a strong control quietly turns into a weak one. The onboarding process belongs in the deliverable alongside the policy.

It confronts the execution step directly, which is why government and security organizations cite application control among the most effective answers to executable file-based malware. It is not absolute, and it removes none of the need for backup, patching, identity controls or antivirus running beside it.

It does. The control restricts not only the applications users can run but code executing in the system core. That reach into kernel mode is part of why it holds up against techniques operating below the level most detection tooling observes.

Scoped by how varied your fleet is, since a uniform estate makes for a far shorter project than one carrying dozens of departmental tools. The free first step costs you an afternoon: take your administrative workstations, write down everything that runs on them, and notice how short the list turns out to be.

Before you author anything

Fifteen questions that decide the shape of the project.

The opening group settles whether this runs three months or twelve, and inventory answers it rather than opinion.

Fleet

How much of our software is signed?
Unsigned software needs explicit rules.
Do departments run their own scripts?
Scripts fall inside the scope.
Do we have engineering or specialist tools?
Reliably the hardest cases.
What Windows editions do we run?
Every mainstream edition supports it.
What Windows versions?
Certain capabilities depend on the version.

Design

App Control or AppLocker?
Requirements and scenarios decide.
Will we enable the Intelligent Security Graph?
Trades explicitness for workability.
Are we starting from the Smart App Control policy?
Strip the lockdown option out first.
How many device groups do we need?
Grouped by application profile.
Who owns the policy long term?
Somebody has to.

Operations

How long will we run audit mode?
Longer than instinct suggests.
Who triages would-have-blocked events?
A genuine workload.
How does new software get approved?
Otherwise people route around it.
Is antivirus staying in place?
It should.
Do we know the passive mode behavior?
Expected, not a fault.

The pages around this one.

Attack surface reduction rules

A lighter-touch control covering adjacent execution paths.

Defender for Endpoint

The detection and response layer that runs beside this.

Intune security baselines

The broader endpoint hardening configuration.

Next step

Write down everything that runs on your administrative workstations.

The list will be short, those machines are the most valuable target you own, and together that makes them the ideal place to begin. Application control on that population is a contained piece of work returning a disproportionate amount of protection.

Book an application control assessment See Microsoft security services

Related Services

Explore more solutions that work great with this service

Antivirus blocks what it recognizes as bad. Application control runs only what you said was good.

Feature

Application control enforced

Audit mode only

Antivirus and ASR rules

Unknown code blocked

Yes

Logged only

Only if detected

Unsigned software controlled

Yes

Visible

Scripts and batch files covered

Yes

Visible

Partly via ASR

PowerShell constrained

Constrained Language Mode

Application inventory accurate

Necessarily

Yes

Frequently not

Effort to maintain

Ongoing

Low

Risk of blocking legitimate work

Managed by audit phase

None

Antivirus still required

Yes

New software needs a process

Yes

Effectiveness against novel malware

High

None

Variable

Code path

Covered

Executables

Yes, the core case

DLLs and code in the system core

Yes, kernel mode code included

Microsoft installers, MSI

Yes

Scripts

Yes

Command-line batch files

Yes

Interactive PowerShell sessions

Yes, held to Constrained Language Mode

Unsigned line-of-business applications

Only where your policy permits them

Code with good cloud reputation

Only with the Intelligent Security Graph enabled

Known malware

Blocked, and unknown code is blocked too

Antivirus role

Still required alongside

Antivirus blocks what it recognizes as bad. Application control runs only what you said was good.

Eight things worth knowing before the first policy is written.

The inversion at the center of it

It reaches well beyond applications

It sits alongside antivirus, not instead of it

Two technologies, and the choice matters

Smart App Control as the starting point

The 48-hour behavior on managed devices

The Intelligent Security Graph option

Licensing that is unusually inclusive

Switching the reputation service on moves Defender Antivirus to passive mode. Nothing is broken.

Four things that keep this project from being abandoned.

We run audit mode for longer than feels necessary

We plan for scripts, not just applications

We decide the reputation question explicitly

We build the onboarding route before enforcing

Four phases across roughly three to four months.

Understand what actually runs

Author policy and run it in audit

Refine until audit is quiet

Enforce progressively and operate

Six situations where application control is proportionate.

An operator with fixed-function workstations

A regulated firm asked about executable control

A business that has had a ransomware scare

A provider with clinical systems on fixed builds

An organization with a small privileged administrator group

A company reducing reliance on detection alone

How US organizations control what executes.

Ten kinds of code, and whether this control governs each one.

Executables

DLLs and code in the system core

Microsoft installers, MSI

Scripts

Command-line batch files

Interactive PowerShell sessions

Unsigned line-of-business applications

Code with good cloud reputation

Known malware

Antivirus role

Five steps, and the third is where the time goes.

Inventory what runs, including scripts

Choose the technology and the trust model

Author and deploy in audit mode

Refine until the audit log is quiet

Enforce progressively and build the onboarding route

What organizations ask about application control.

How is this different from antivirus?

Can we replace antivirus with this?

Does it cover scripts?

Do we need Enterprise licensing?

Should we use App Control or AppLocker?

Is Smart App Control protecting our managed devices?

Is the Smart App Control policy a reasonable foundation for ours?

Why did Defender Antivirus go into passive mode?

What does the Intelligent Security Graph do, and is enabling it wise?

How long does audit mode need to run?

What if we enforce too early?

Where should we deploy it first?

What happens when somebody needs new software?

Does this stop ransomware?

Does it protect the kernel as well as applications?

What does an engagement cost?

Fifteen questions that decide the shape of the project.

Fleet

Design

Operations

The pages around this one.

Attack surface reduction rules

Defender for Endpoint

Intune security baselines

Write down everything that runs on your administrative workstations.

Related Services

Attack Surface Reduction Rules Deployment

Microsoft Defender for Endpoint Services

Intune Security Baselines

Endpoint Security

Microsoft Defender

Antivirus blocks what it recognizes as bad. Application control runs only what you said was good.

Eight things worth knowing before the first policy is written.