praddsouza That does not entirely match up with my experience thus far when it comes to digital signatures and VBA projects. In the macro-enabled workbook that I manage, the VBA project is password-locked, the workbook structure is password-protected, and a new blank worksheet can be added programmatically via a command button and associated macro.
The model can be saved after programmatic insertion of a new blank worksheet without the digital signature being discarded, as long as you don't enter the password to unlock the VBA project and view the code module attached to the new worksheet object - which may (depending on your VBE settings) add directives at the top of the module by default (e.g. Option Explicit), thereby changing the VBA project.
The new worksheet inserted programmatically can also be deleted via command button/associated macro without affecting the VBA project/digital signature.
An existing worksheet can also be deleted programmatically without affecting the VBA project/digital signaature, as long as the code module attached to the worksheet object being deleted is empty, e.g. there is no Worksheet_Change event procedure code related to the sheet.
So it's all about structuring your project such that critical code is not attached to worksheets which the end user is able to delete. If your experience is different, I assume that either your workbook is not protected, meaning users can freely delete core worksheets that have VBA code associataed with them, or if the workbook is protected, then there remains a programmatic way via user interface operations (command buttons etc) that users are able to delete these core worksheets with associated VBA code.
In that latter case, it would be sensible to review your project's structure and remove that ability to programmatic deletion of those worksheets, or move any associated code to a module/worksheet object which cannot be programmatically deleted. In the former case, I would strongly suggest workbook protection and VBA project protection.