Historical article
- Original title: SSIS Packages are Encrypted by Default
- Author: Brian Knight
- Original publication date: December 19, 2005
- Originally published on: White Knight Technology
- Preservation note: This article preserves the material recovered from the Wayback snapshot.
Archive provenance: White Knight Technology Historical Archive
By default, SSIS packages in development used encryption to keep an unauthorized person from seeing sensitive package content. The default EncryptSensitiveWithUserKey behavior was tied to the user and workstation. If a developer sent a package to another developer, or signed in under another user account, that other user could not decrypt the protected content by default.
The resulting package-load message could be misleading:
There were errors while the package was being loaded. The package might be corrupted. See the Error List for details.
The package was not necessarily corrupt. The originating user's key had protected its sensitive content. The package owner could open the package and choose another ProtectionLevel in the Properties pane. The default was EncryptSensitiveWithUserKey; to protect the entire package with a password, the historical alternative described was EncryptAllWithPassword.
The original article also described using a batch file when packages were ready to move toward production. It looped through the directory's .dtsx files and used Dtutil.exe to apply a password:
for %%f in (\\*.dtsx) do Dtutil.exe /file %%f /encrypt file;%%f;3;newpassword
That command assigned newpassword to each matching package. The production support group could then use a similar batch operation to reset the packages to a production password.
Context and evidence
The archived White Knight Technology article is the primary recovery evidence. A SQLServerCentral discussion explicitly linked Brian Knight's original page in 2006. A handleError context URL was also retained as recovery context; its current destination does not reproduce the historical article and should not be treated as the primary source.
2026 Update
The batch command and its command-line password handling are historical and must not be copied into production. A literal password in a script, shell history, process arguments, build log, or source repository can expose a credential.
For current SSIS project-deployment workflows, use project parameters and SSIS Catalog environments to separate deployable packages from environment-specific values. Keep secrets in an appropriately controlled secret store and inject or reference them through the supported deployment platform. This modern note supplements the preserved 2005 article; it does not replace or rewrite the historical material above.