If you have a standard code signing certificate, some time will be needed for your application to build trust. Microsoft affirms that an Extended Validation (EV) Code Signing Certificate allows to skip this period of trust building. According to Microsoft, extended validation certificates allow the developer to immediately establish reputation with SmartScreen. Otherwise, for some time, until your application builds trust, the users will see a warning like "Windows Defender Smartscreen prevented an unrecognized app from starting. Running this app might put your PC at risk.", with the two buttons: "Run anyway" and "Don't run".
Another Microsoft resource states the following (quote): "Although not required, programs signed by an EV code signing certificate can immediately establish reputation with SmartScreen reputation services even if no prior reputation exists for that file or publisher. EV code signing certificates also have a unique identifier which makes it easier to maintain reputation across certificate renewals."
My experience is the following. We have used regular (non-EV) code signing certificates for signing .MSI, .EXE and .DLL files since 2005, with timestamping, and never had problems with SmartScreen, until 2018, when there were just one case when it took 3 days for a beta version of our application to build trust since we have released it to beta testers, and it was in the middle of certificate validity period. I have no idea what the SmartScreen might not have liked in that particular version of our application, but there were no complaints since then. Therefore, if your certificate is a non-EV, it is a signed application (such as an .MSI file) that will build trust over time, not a certificate. As in our case, a certificate can be issued a few months ago and used to sign many files, but for each signed file you are publishing, it may take several days for SmartScreen to stop complaining about the file after it is published.