Developer ID : renouveler les certificats Mac avant février 2027

Article créé le 2 octobre 2026 · Source analysée le 2 octobre 2026 · Source officielle publiée le 1er octobre 2026 : Apple Developer · Thème : sécurité Mac, signature et déploiement

Apple avertit que l’autorité intermédiaire Developer ID d’origine expirera le 1er février 2027. Pour les entreprises qui distribuent des applications ou des paquets d’installation Mac hors du Mac App Store, cette échéance doit devenir un chantier de continuité : les paquets .pkg signés avec un certificat affecté ne s’installeront plus après cette date.

1. Ce qu’Apple annonce précisément

Les certificats émis par l’ancienne sous-autorité cesseront de fonctionner le 1er février 2027. Apple demande de repérer, dans Certificates, Identifiers & Profiles, les certificats qui expirent au plus tard à cette date, puis de créer un certificat lié à l’autorité Developer ID Certification Authority (G2).

L’autorité G2 est valide jusqu’en 2031, mais Apple rappelle que les certificats qu’elle émet doivent être renouvelés chaque année. Xcode 11.4 ou une version antérieure doit être mis à jour avant la création du nouveau certificat. Lors du choix de l’intermédiaire, il faut sélectionner G2 Sub-CA : une autre option peut encore produire un certificat expirant en 2027.

2. Paquets et applications Mac : deux traitements différents

Apple distingue clairement les formats. À partir de l’échéance, un paquet .pkg signé avec un certificat affecté ne pourra plus être installé : tous les paquets encore distribués doivent être re-signés avec le nouveau certificat.

Une application Mac déjà signée, notarée et accompagnée d’un horodatage sécurisé continuera en revanche à fonctionner. Il n’est pas nécessaire de la re-signer uniquement pour cette échéance. Les futures versions doivent utiliser le nouveau certificat et conserver l’horodatage sécurisé lors de la notarisation.

3. Où se situe le risque dans un parc d’entreprise

Le certificat n’est souvent qu’un maillon d’une chaîne plus longue : construction CI/CD, signature, notarisation, dépôt de paquets, politiques Jamf ou autre MDM, Self Service et procédures de reprise. Un ancien paquet rarement utilisé — agent de sécurité, pilote, outil VPN ou installateur de secours — peut rester dans un dépôt bien après le renouvellement du certificat.

Changer uniquement le certificat du prochain build laisse donc un risque résiduel. L’inventaire doit couvrir les paquets actifs, les versions épinglées, les copies de secours, les recettes d’automatisation et les identités de signature conservées dans les coffres de secrets.

4. Qu’est-ce que cette annonce change pour une entreprise belge ou française ?

L’échéance est mondiale : une PME belge qui distribue un utilitaire interne est concernée comme une ETI française ou un groupe européen. L’impact est surtout opérationnel. Un paquet indispensable qui ne s’installe plus peut bloquer l’arrivée d’un collaborateur, la remise en conformité d’un Mac ou la restauration d’un poste.

Les DSI doivent identifier le propriétaire de chaque binaire et imposer une preuve de test avant février. Les équipes sécurité doivent protéger et tracer la nouvelle clé privée. Les achats et responsables applicatifs doivent obtenir une version re-signée lorsqu’un éditeur ou intégrateur externe fournit les paquets.

5. Lecture Underside : traiter le certificat comme une dépendance de production

Notre lecture est que ce changement relève moins d’une formalité développeur que de la gestion du cycle de vie Mac. Apple Business Manager et Automated Device Enrollment enrôlent l’appareil ; Jamf ou un autre MDM orchestre l’installation ; mais ni l’un ni l’autre ne répare un paquet dont la chaîne de signature est arrivée à expiration.

Le contrôle doit rejoindre la gouvernance des paquets macOS gérés par MDM et la qualification des applications métier Apple. Le bon indicateur n’est pas « certificat renouvelé », mais « chaque artefact encore déployable a été identifié, re-signé si nécessaire et testé par son canal réel ».

6. Plan d’action avant le 1er février 2027

• Inventorier les certificats Developer ID, leur sous-autorité, leur date d’expiration, leur propriétaire et leurs usages.
• Créer les remplacements via G2 Sub-CA avec une version actuelle de Xcode, puis sécuriser les clés privées et les droits d’accès.
• Recenser tous les paquets .pkg encore disponibles dans le MDM, Self Service, les dépôts et les procédures de secours.
• Re-signer les paquets concernés, vérifier leur signature et leur notarisation, puis les tester sur un Mac pilote par le canal de production.
• Confirmer que les apps existantes conservées reposent sur une notarisation et un horodatage sécurisés ; utiliser le nouveau certificat pour les versions futures.
• Documenter le renouvellement annuel et retirer les anciens certificats, clés et artefacts selon une procédure contrôlée.

Source officielle : Apple Developer — Upcoming expiration of Developer ID Certification Authority (Sub-CA).