Retour au blog

Attestation des passkeys Apple : cadrer identité et MDM

Article créé le 4 octobre 2026 · Source analysée le 4 octobre 2026 · Matrice officielle mise à jour le 17 septembre 2026 : Apple Platform Deployment · Thème : passkeys, identité et sécurité Apple

Apple permet à une organisation de vérifier, au moyen d’un certificat présenté lors du provisionnement, qu’une passkey a été créée sur un appareil géré. Cette preuve peut renforcer une architecture d’identité, à condition que le MDM, l’autorité de certification et le service web partagent une politique précise.

1. Ce que l’attestation prouve réellement

La configuration déclarative Passkey Attestation autorise l’attestation d’entreprise WebAuthn pour des passkeys associées à des domaines définis. Apple indique que l’attestation prend la forme d’un certificat utilisé pendant le provisionnement. Elle permet donc au service destinataire d’obtenir une preuve liée au contexte géré de création de la passkey.

Cette preuve ne remplace ni l’authentification de l’utilisateur, ni les règles d’accès conditionnel, ni l’évaluation continue de la conformité. Elle ne doit pas non plus être confondue avec Managed Device Attestation, qui porte sur les propriétés et l’identité cryptographique de l’appareil.

2. Prérequis Apple et limites à valider

La matrice Apple mise à jour le 17 septembre 2026 maintient la disponibilité à partir d’iOS 17, iPadOS 17 et macOS 14, avec des portées appareil ou utilisateur selon la plateforme. Apple documente Device Enrollment et Automated Device Enrollment, mais pas User Enrollment. La supervision n’est pas exigée par la page de configuration.

La déclaration exige une identité d’attestation issue d’un asset certificat ACME, SCEP ou PKCS#12 et une liste de relying parties. Seuls les domaines explicitement définis peuvent demander l’attestation lors de la création d’une passkey. Sur macOS, un réglage optionnel contrôle si la clé privée de cette identité est extractible ; ce choix doit être aligné avec la politique de protection des clés.

3. Qu’est-ce que cela change pour une entreprise belge ou française ?

Pour une PME, l’intérêt existe surtout lorsqu’un fournisseur d’identité ou une application métier sait consommer cette attestation ; activer une déclaration isolée n’apporte aucune valeur. Pour une ETI, un grand groupe ou une administration, elle peut aider à distinguer les passkeys provisionnées dans un contexte géré des autres credentials, notamment pour les applications sensibles.

Dans l’Union européenne, la preuve technique doit rester proportionnée à la finalité. Les équipes sécurité et conformité doivent documenter les domaines autorisés, les données transmises, la durée de vie du certificat et le traitement des appareils réattribués ou retirés du MDM. Le contrôle doit soutenir une politique d’accès explicite, pas devenir une collecte indifférenciée.

4. Lecture Underside : concevoir la chaîne de confiance avant le profil

Notre lecture est que la difficulté n’est pas la déclaration MDM elle-même, mais l’alignement entre quatre composants : annuaire et fournisseur d’identité, service MDM, infrastructure de certificats et relying party WebAuthn. Si l’un ne sait pas émettre, distribuer, demander ou valider la preuve, le projet reste incomplet.

Dans Jamf ou un autre MDM Apple, il faut d’abord confirmer l’implémentation exacte de la configuration et des assets d’identité. Apple précise que tous les réglages ne sont pas proposés par tous les services de gestion. Le périmètre doit ensuite être rapproché d’Apple Business, d’Automated Device Enrollment et du modèle d’identité retenu, sans supposer que l’attestation autorise automatiquement l’accès.

5. Plan de déploiement recommandé

Objectif : utiliser l’attestation comme un signal vérifiable dans la politique d’identité, avec des domaines, certificats et règles de repli maîtrisés.

Cadrer un projet passkeys et MDM Apple

Sources officielles : Apple Platform Deployment — Passkey Attestation declarative configuration et Apple Developer — SecurityPasskeyAttestation.