It depends on the profile type. With a leaked certificate and matching provisioning profile, an attacker can sign an app that carries your bundle identifier. Whether that matters turns on whether it is an App Store, development, ad hoc or enterprise profile, and on what store credentials they also hold.
Definitions in one minute
A signing certificate proves who built an app. Its private key does the signing. A provisioning profile ties a certificate, an app identifier and, for some types, a list of devices together. Having the certificate and profile lets someone produce a build your devices or the store will treat as yours, within the limits of that profile.
What each profile type allows
This summary follows the worst case analysis in the fastlane match documentation, which is a reasonable public reference.
| Profile type | What a thief can do | What limits them |
|---|---|---|
| App Store | Sign an upload, but it is not usable until Apple re-signs it after review | Needs store login to submit |
| Development | Install a signed app on a small set of registered devices | Adding devices needs developer portal login |
| Ad hoc | Same, on registered devices | Same |
| Enterprise (in-house) | Distribute to a potentially unlimited number of devices under your name | Little, other than revocation |
The same page notes that you also receive an email whenever a build is uploaded, which gives a chance to cancel a submission before review. Do not count on that as a control; mailboxes get ignored.
The caveat that matters on CI
Those limits assume the attacker has the signing files but not your store credentials. A compromised build server often has both, because the pipeline needs both to ship a build. So treat a CI compromise as a full signing and publishing compromise until proven otherwise.
What to do after a leak
- Identify which certificate and which profile types were exposed. Inventory first, act second.
- Revoke the exposed certificate in the developer portal, then regenerate certificates and profiles.
- Rotate every store credential the same environment could reach, including any API key.
- Review recent uploads and submitted builds for anything you did not make.
- Check where the files lived. A secrets store, a repo, a build cache and a log are all possible leak points. Our post on what to cache and what never to cache covers the cache case.
- Record dates and actions for your incident file.
The fastlane documentation adds that revoking an enterprise certificate is the way to remotely break an app signed with it on devices, which is also why a leaked enterprise certificate is the most urgent type to revoke.
Reduce the blast radius before it happens
Use App Store profiles for production, keep enterprise signing off the shared pipeline unless it is needed, keep the passphrase apart from the storage, and give CI a store role with only the permissions the lane needs. None of this removes the risk, but each step shrinks what one leak buys.
Where Safeguard fits
Safeguard covers the software around your build: SBOM and dependency scanning, reachability analysis, policies and release gates. It does not manage Apple certificates. A free scan shows what your app ships.
Quick check
Is an App Store profile dangerous if leaked?
On its own it is the least useful type to a thief, because a build still needs review and a store login. Do not rely on that if CI holds both.
Which profile type is the most urgent to revoke?
Enterprise, because it can distribute to many devices under your company name.
Sources
Last reviewed: 19 October 2026.
