It can be, with conditions. Tools in the fastlane match style keep encrypted certificates and provisioning profiles in a private git repo you control. That is only as safe as the repo's access list, the encryption passphrase, and the separate credentials needed to publish. Treat the repo as a vault, not a convenience folder.
What the match approach actually stores
Match is an open-source action that creates the certificates and provisioning profiles an iOS or macOS app needs and keeps them in shared storage so every machine signs with the same identity. Its documentation lists three storage options: a private git repository, Google Cloud Storage, or Amazon S3.
For git storage, the documentation says keys and profiles are encrypted with OpenSSL using a passphrase. For Google Cloud Storage it says they are encrypted with Google managed keys. In every case, "private" and "encrypted" are the two properties you are relying on.
Where the real risk sits
There are three separate locks, and a leak of one should not open the others.
| Lock | What it guards | Typical failure |
|---|---|---|
| Repo or bucket access | Who can fetch the encrypted files | Too many readers, a stale deploy key |
| Encryption passphrase | Whether fetched files are readable | Passphrase pasted in a chat or a wiki |
| Store publishing credentials | Whether a signed build can be submitted | Account password shared in CI variables |
The match documentation argues that stolen certificates alone are of limited use. An App Store profile is not useful until the app is submitted for review, and that needs App Store Connect credentials, which the doc says are not kept in git. Development and ad hoc profiles are described as limited to a small set of devices. Enterprise (in-house) profiles are the exception: the same page warns they can be used to distribute to a potentially unlimited number of devices under your company name, and tells you to use them with caution.
One caution is worth adding from experience of how CI is usually set up. That argument assumes the passphrase and the store credentials live in different places. On a build server they often sit in the same secret store, so one compromise of CI yields both halves. Separate them where you can, and give the CI identity the narrowest store role that still works.
A practical setup
- Use a private repository dedicated to signing material, not the app's source repo.
- Limit read access to the people and CI identities that sign. Review the list on a schedule.
- Turn on two-factor authentication for every account with access. The match documentation recommends this for GitHub and Bitbucket accounts that can reach the certificates repo.
- Store the passphrase in your secret manager, never in the Matchfile or the repo.
- Run in read-only mode on CI so a build can fetch but never create or revoke certificates. The documentation recommends read-only mode for CI.
- Avoid enterprise profiles unless you truly need them.
When another approach fits better
If your team is tiny and releases rarely, a single signing machine plus a safely stored backup of the exported private key may be simpler. The fastlane codesigning guide notes that a lost private key file cannot be restored, so a backup matters either way. If you want fewer moving parts and accept less control, Xcode's managed signing is another path. Pick based on who needs to sign and how often, not on what is trendy. Our post on choosing a signing approach compares them.
Where Safeguard fits
Safeguard does not store your signing keys. It helps with the dependencies around the pipeline: SBOM and dependency scanning, reachability analysis, and policies that gate a release. You can try a free scan on a repository.
Quick check
Is a private repo enough on its own?
No. Privacy controls who can read the files, but the passphrase and the publishing credentials are separate protections. Keep all three apart.
Should CI be allowed to create new certificates?
Usually not. Read-only mode lets CI fetch what it needs without creating or revoking anything, which limits the damage from a bad run.
Sources
Last reviewed: 19 October 2026.
