Forum Discussion
Excel + IRM: Allow VBA to edit protected cells / insert rows without granting "Full Control"
You want a fully stand-alone Excel workbook, protected via IRM/MIP, where VBA can modify protected cells or insert rows, without granting users Full Control (so far i understand).
Excel + IRM / MIP Limitations
There is no native Excel/MIP setting that allows macros to bypass protected cells under IRM without Full Control. Any attempt to do Sheet.Unprotect or InsertRows via VBA will fail unless the user has Full Control permissions.
Why UserInterfaceOnly = True fails
- UserInterfaceOnly allows macros to edit protected sheets without unprotecting them, but this does not override IRM restrictions.
- IRM protection is applied at a level below the Excel object model — macros cannot bypass it unless the file is opened by a user with Full Control.
There is no Excel-native way to allow macros to bypass IRM/MIP cell protections without Full Control. IRM is designed intentionally to enforce governance, including programmatic access restrictions.
UserInterfaceOnly = True only works with normal Excel protection, not IRM-protected workbooks.
For fully stand-alone usage, you either:
- Avoid IRM for the editable areas and rely on sheet protection + passwords, or
- Use a split model where the IRM master file is read-only, and macros write to a separate unprotected workbook.
If your goal is stand-alone VBA automation with cell editing under IRM, Microsoft’s current model does not support it without granting Full Control. Any workaround requires either:
Relaxing IRM to allow normal sheet protection, or
External service identity (Power Automate, service account) to handle edits under IRM.
Excel-native alternatives (stand-alone)
Given that you cannot bypass IRM programmatically without Full Control, the closest Excel-native options are:
Approach
Pros
Cons
Use normal sheet protection (password) instead of IRM for cells/macros
UserInterfaceOnly=True works; macros can insert rows/update formulas
Does not prevent copying file outside the domain
Split workbook into master (IRM) + editable local sheets
Sensitive data remains IRM-protected; users edit local sheet macros
Adds complexity, requires sync logic
VBA temporarily unprotect with a password
Stand-alone macros work on protected cells
Password must be embedded (security risk)
I apologize that I cannot offer a reasonable solution, but the available options do not allow it.
My answers are voluntary and without guarantee!
Hope this will help you.
Thank you very much for the detailed answer and guidance.
The architecture you described with Power Automate and a service identity makes perfect sense from a governance and compliance standpoint.
However, in our current scenario, we’d prefer to keep the workbook fully stand-alone — without external connectors or Power Automate flows — since it’s distributed internally to multiple business units that work offline or in restricted environments
Our goal is to understand whether there’s any Excel-native configuration (IRM, MIP label, or registry policy) that would allow VBA macros to edit protected cells or use UserInterfaceOnly = True under IRM, without granting “Full Control” to users.
You want a fully stand-alone Excel workbook, protected via IRM/MIP, where VBA can modify protected cells or insert rows, without granting users Full Control (so far i understand).
Excel + IRM / MIP Limitations
There is no native Excel/MIP setting that allows macros to bypass protected cells under IRM without Full Control. Any attempt to do Sheet.Unprotect or InsertRows via VBA will fail unless the user has Full Control permissions.
Why UserInterfaceOnly = True fails
- UserInterfaceOnly allows macros to edit protected sheets without unprotecting them, but this does not override IRM restrictions.
- IRM protection is applied at a level below the Excel object model — macros cannot bypass it unless the file is opened by a user with Full Control.
There is no Excel-native way to allow macros to bypass IRM/MIP cell protections without Full Control. IRM is designed intentionally to enforce governance, including programmatic access restrictions.
UserInterfaceOnly = True only works with normal Excel protection, not IRM-protected workbooks.
For fully stand-alone usage, you either:
- Avoid IRM for the editable areas and rely on sheet protection + passwords, or
- Use a split model where the IRM master file is read-only, and macros write to a separate unprotected workbook.
If your goal is stand-alone VBA automation with cell editing under IRM, Microsoft’s current model does not support it without granting Full Control. Any workaround requires either:
Relaxing IRM to allow normal sheet protection, or
External service identity (Power Automate, service account) to handle edits under IRM.
Excel-native alternatives (stand-alone)
Given that you cannot bypass IRM programmatically without Full Control, the closest Excel-native options are:
Approach | Pros | Cons |
Use normal sheet protection (password) instead of IRM for cells/macros | UserInterfaceOnly=True works; macros can insert rows/update formulas | Does not prevent copying file outside the domain |
Split workbook into master (IRM) + editable local sheets | Sensitive data remains IRM-protected; users edit local sheet macros | Adds complexity, requires sync logic |
VBA temporarily unprotect with a password | Stand-alone macros work on protected cells | Password must be embedded (security risk) |
I apologize that I cannot offer a reasonable solution, but the available options do not allow it.
My answers are voluntary and without guarantee!
Hope this will help you.