I work at a large company where Python is increasingly used by developers and nontechnical staff. A recent Windows security-policy change blocks executables that do not have a digital signature. This affects pip.exe and similar launchers, command-line scripts generated from package entry points, PyInstaller applications, and scripts inside virtual environments.
Most Python-generated launchers are small executable wrappers that invoke Python and load the relevant package code. Because each launcher contains different metadata or script content, their hashes differ, so creating one general allowlist entry is difficult. PyInstaller binaries also bundle the application, dependencies, and Python runtime.
I considered replacing the launchers with batch files, but maintaining that workaround would require handling synchronization after package installation or removal, multiple Python versions, virtual environments, tools such as Poetry, and possible cleanup if the workaround becomes incomplete. What is the recommended enterprise solution? Can security administrators create a rule that recognizes trusted Python launchers, or should these applications be signed and allowlisted? Is there a supported way to configure pip or the packaging tools to generate batch-file launchers instead of Windows executables?
4 Answers
For many Python command-line tools, use the module form instead of invoking the generated executable directly: `python -m pip`, or `python -m package_name`. This avoids some launcher files and makes it explicit which Python installation is being used. It will not replace every console entry point, especially packages with several commands, but it is a useful option for tools that provide a module entry point. Virtual environments can be handled by invoking that environment’s Python explicitly.
The clean solution is to work with the security or IT team rather than patching pip or replacing launchers behind their back. Applications that are distributed as binaries should normally be signed with an organizational code-signing certificate and deployed through the company’s approved process. Security tools may still inspect signed programs, but signing gives administrators a way to establish publisher-based trust instead of maintaining hashes for every generated file.
A signature is not automatically an antivirus exemption; the file can still be blocked based on its behavior or reputation. It mainly makes controlled publisher-based deployment and allowlisting possible.
If the policy is based on application control, security administrators may be able to allow trusted publishers, installation directories, package paths, or approved interpreter-and-script combinations rather than individual hashes. They should evaluate the actual control product and threat model, since simply allowing all Python scripts or all files under user-writable directories would undermine the policy. Suspicious PyInstaller applications should be reviewed and submitted to the vendor for analysis when appropriate.
If Python itself is allowed but arbitrary child processes are restricted, the security team may need a narrowly scoped rule for approved interpreters, signed internal applications, or managed deployment locations instead of a blanket exception.
Avoid self-deleting or self-modifying launchers, patching pip, and silently rewriting PATH entries. Those behaviors look suspicious to endpoint protection and make the system difficult to support. A better model is to use standard Python installations and virtual environments, then distribute approved wheels or applications through a managed process. Tools such as uv can simplify installing and maintaining environments, but they still need to comply with the company’s execution policy.
This does not work for every package because a package can expose multiple entry points without providing equivalent `__main__.py` behavior. It is still suitable for commands such as pip and other packages designed around module execution.