Prevent Microsoft Office from Injecting Code
Microsoft Office is configured to not insert code into other programs for security reasons.
Plain language
This control is about stopping Microsoft Office from inserting its code into other software on your computer. It matters because if Office could easily inject code elsewhere, it might open the door for hackers to exploit that capability, leading to data theft or malicious software spreading without you knowing.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Aug 2021
Control Stack last updated
19 Mar 2026
E8 maturity levels
ML2, ML3
Guideline
Guidelines for system hardeningSection
User application hardeningOfficial control statement
Microsoft Office is blocked from injecting code into other processes.
Why it matters
If Microsoft Office can inject code into other processes, attackers can use Office to run malicious code in trusted apps, enabling malware spread and data compromise.
Operational notes
Enable and audit the Defender ASR rule ‘Block Office applications from injecting code into other processes’, monitor alerts, and restrict any exceptions to approved cases.
Implementation tips
- The IT team should adjust settings within Microsoft Office to prevent it from injecting code into other applications. They can do this by accessing the Office application settings and modifying the security settings related to code execution and integration with other software.
- Managers should work with their staff to ensure they understand how to spot any suspicious activity related to unexpected Microsoft Office behaviour. Conduct a short training session to explain what unusual behaviour looks like, such as Office applications trying to access other programs without warning.
- System administrators should regularly update Microsoft Office software. They can schedule automatic updates or routinely check for new updates through Microsoft's update service to ensure any known vulnerabilities are patched.
- Procurement officers should ensure that all purchased software including Office is bought from legitimate sources. Verify licences and purchase records to avoid using pirated versions, which are more likely to have security risks enabling code injection.
- Security officers should monitor the use of Office applications with network security tools. Set up alerts for activities that seem odd, such as Office files that are interacting with other parts of the system without a clear reason.
Audit / evidence tips
-
Aska list of Microsoft Office security settings: Request a document or screenshot showing how Office is configured on systems to prevent code injection
Goodwill show these features are set to 'disabled' or 'restricted.'
-
Askthe results of any recent IT security audits involving Microsoft Office: Request copies of the reports
Goodis an audit that specifically confirms code injection protections are active
-
Asktraining materials given to staff about Microsoft Office use and security: Check the content for clear advice about preventing unauthorised actions by Office applications
Goodincludes mentions of recognising unusual Office behaviour
-
Askdocumentation on the software update process: This should outline how often Office is updated and who is responsible
Goodincludes a log of past updates applied
-
Askprocurement records for Microsoft Office licences: Review them to ensure all software in use has legitimate licences
Goodshould rely on clear documentation from official vendors or Microsoft itself
Cross-framework mappings
How ISM-1669 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 8.9 | ISM-1669 requires Microsoft Office to be blocked from injecting code into other processes | |
E8
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| sync_alt Partially overlaps (4) expand_less | ||
| link Related (1) expand_less | ||
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.