Note: I won't go into any Maven tool specifics, firstly on the basis that I'm not all that familiar with Maven itself, and secondly that questions about how to use particular tools are off-topic and belong on StackOverflow.
In general (and the case for Maven), most package/artefact services and tools are nothing more than generic repositories which are agnostic to the content of the files they serve, but whose tools also happen to have additional support which lend themselves to a particular programming language.
With that in mind, Maven along with most other similar tools are well-suited for serving generic, packed archive files such as
.tar, making them convenient 'mirrors' for 3rd party dependencies.
Related question on StackOverflow: https://stackoverflow.com/questions/25441633/how-to-deploy-only-zip-artifacts-in-maven
Using a package repository as a mirror provides a safety net against problems with external sources, including availability, the chance that any 3rd party might make a change which breaks your build process, and helps development teams unify all of their devops processes around a single tool, so I would consider the use of a private package repository for this purpose as a fairly standard approach.
I'd suggest unifying around a single portable archive format such as .zip for all 3rd-party dependencies. Even if the particular file you want to host uses some other archive format such as MSI, it should be trivial to put an MSI inside a zip when publishing it, and then extracting it as part of the build process. All consumers of all 3rd-party artefacts/dependencies can then rely on a single consistent method for retrieving and unpacking those dependencies.
Settling on an archive format such as .zip also solves any problems if other files need to be included - for example, you might want to ensure all 3rd-party packages contain some setup/deploy script and a readme.
Given that these large files are currently stored in git, and that deleting a file from git doesn't erase git history, the git repositories won't shrink just by moving those files out, some invasive surgery will be needed:
I would recommend a great deal of caution and coordination with everyone who uses these git projects. Consider forking the git repository, making the original repository read-only, asking developers to move to the new fork, so that any erased history isn't lost forever in case anything goes wrong. You may wish to keep the original read-only repository hanging around for as long as it contains any historic tags or release branches which still need to be supported.
To verify that nothing has broken, clone both the original and changed repositories side-by-side and use HEAD commits in each of your main/master branches to ensure there are no differences; remember to also check other long-lived branches (if applicable) - for example, any current/recent release branches, and any active development branches. (Ideally arrange to do the work when there are as few active branches as possible). This may seem over-cautious, but it should be a one-time deal for each repository.