WMI can be secured to be safe for internal networks following some configuration steps:
The most immediate issue (to me) is requiring encryption in transit to mitigate snooping (excerpt of above):
An administrator or a MOF file can configure a WMI namespace so that no data is returned unless you use packet privacy (RPC_C_AUTHN_LEVEL_PKT_PRIVACY or PktPrivacy as a moniker in a script) in a connection to that namespace. This ensures that data is encrypted as it crosses the network. If you try to set a lower authentication level, you will get an access denied message. For more information, see Requiring an Encrypted Connection to a Namespace.
The next most important thing is least privilege via RBAC. You should limit the asset management product's account to read-only WMI operations and if possible limit what it can read to what is needed. This is achieved via Namespace Security and is described further here:
You may need to allow certain write privileged if the asset management software also performs actions on the endpoints rather than just auditing. Press the vendor for a least privilege configuration.
Once you have that you should generate high entropy random values (using all the characters and maximum length the asset management tool will work with) for both the username and password. These credentials should be stored in a secure password management system like Thycotic Secret Server or a local secure password manager such as KeePass for which you maintain backups. You can probably use a non-random username, but that does increase risk somewhat if it's easily guessed and using a random username given how infrequently you need to manage it gives you a free security boost.
After all that you should set Windows Firewall with Advanced Security to allow the DCOM connections needed for WMI only on the port it is running on and only from the host (or hosts if you are doing HA) running the asset management software. This is the final layer of the defense in depth here and makes it harder for attackers to exploit even of they have the credentials.
Single Purpose Single Server/VM
The asset management software should be run on its own on a dedicated server or VM. The firewall whitelist is far less useful if it's on a misc app server with all the other junk a network needs. Running it with other software or services also exposes it and the credentials to unnecessary local attack risks.
You may be able to bake those steps into a GPO.
Alternative solution: PowerShell
An alternative (though incompatible with you asset management product) is PowerShell Remoting. It uses TLS and GSSAPI authentication integrated with AD so I'm very comfortable with it. We use it in production.
Once you have PowerShell remoting you can log into a system remotely with Enter-PSSession %MachineName%. You can also use Invoke-Command with -ScriptBlock to run a command remotely and get results centrally for coordination. Your WMI commands could be run that way.
Here's a guide on enabling PowerShell Remoting:
The challenge with either of these is transitive trust and lateral movement. Be careful that the accounts allowed to make this jump between machines have very strong passwords. We use per-person 100 character full ASCII random generated passwords for this that we rotate every 90 days. We use KeePass to autotype these as they aren't practical to type by hand.