Ripensare la proprietà del CIAM in azienda

1. Introduzione#

Chiedi a dieci aziende chi possiede l'identità del cliente o del consumatore (CIAM) e otterrai dieci risposte diverse. A volte è l'ufficio del CISO. A volte è il CTO, perché il CIAM deve essere integrato direttamente nell'app, nel sito web e nelle API che forniscono il prodotto. A volte è il CPO. A volte è un team antifrode che ha preso il controllo pezzo per pezzo perché nessun altro aveva il quadro completo. Spesso non è di nessuno e il sistema viene tenuto in vita da un ingegnere DevOps che lo ha ereditato tre riorganizzazioni fa.

Il Gartner CIAM Magic Quadrant inquadra l'IAM per i clienti attorno a cinque ambiti funzionali (registrazione, autenticazione, autorizzazione, self-service e analisi) che quasi mai si mappano in modo netto su un singolo team. Secondo Grand View Research, il mercato globale del CIAM è stato valutato a 8,12 miliardi di dollari nel 2023 e si prevede che raggiungerà i 26,72 miliardi di dollari entro il 2030, con un tasso di crescita annuale composto (CAGR) del 17,4%. I problemi di proprietà aumentano in proporzione a tale spesa.

Il CIAM è uno dei programmi più interfunzionali che la maggior parte delle aziende B2C gestisca. Si trova all'incrocio tra sicurezza, ingegneria, prodotto, frode e crescita, e ciascuna di queste funzioni ottimizza per una metrica diversa. La proprietà decide quale metrica vince in caso di conflitto. Una proprietà ambigua significa che non vince nulla e il programma di identità va alla deriva.

Questo articolo ripensa la proprietà del CIAM per l'azienda moderna: i profili comuni dei proprietari, come il settore di appartenenza plasma la risposta, perché i dati frammentati e la cultura del "non è un mio problema" mantengono aperta la questione e come si presenta un modello operativo condiviso quando non è in discussione una riorganizzazione.

1.1 Domande a cui risponde questo articolo#

In questo articolo affrontiamo le seguenti domande:

1. Perché la proprietà del CIAM è ambigua nella maggior parte delle aziende e quanto costa effettivamente tale ambiguità?
2. Chi sono i proprietari comuni del CIAM e come ciascuno di essi ottimizza il programma in modo diverso?
3. Perché la frammentazione della proprietà è spesso correlata all'assenza di un livello di analisi dell'autenticazione?
4. In che modo il contesto del settore (e-commerce rispetto al settore bancario rispetto al B2C regolamentato) cambia la risposta?
5. In che ambito la proprietà divisa causa più danni?
6. Quali KPI del CIAM nessuno possiede appieno, ma ogni team richiede?
7. Come si presenta una scorecard CIAM condivisa e come si implementa senza una riorganizzazione?

2. Il problema del lancio della moneta#

2.1 Perché il CIAM è il programma più interfunzionale di cui disponi#

L'identità del cliente e del consumatore tocca tutto. Decide se un utente può acquistare, rinnovare, recuperare l'accesso o raggiungere una funzionalità regolamentata. L'ufficio del CISO se ne preoccupa perché ogni evento di autenticazione è un evento di sicurezza. L'ufficio del CTO se ne preoccupa perché il CIAM deve essere integrato nell'app, nel sito web e nelle API, e ogni modifica al login viene rilasciata insieme al vero codice del prodotto. L'ufficio del CPO se ne preoccupa perché ogni evento di autenticazione è un evento di conversione. Il team frodi se ne preoccupa perché ogni step-up è un segnale di frode. Il team growth se ne preoccupa perché la personalizzazione dipende dall'identificazione dell'utente. Nessun altro sistema ha cinque proprietari legittimi allo stesso tempo.

2.2 Costo della proprietà ambigua#

Il costo è visibile nei rollout delle passkey. I rilasci che si bloccano al 5% o al 15% di adozione hanno quasi sempre una cosa in comune: nessun singolo proprietario ha gestito il rollout dall'inizio alla fine. La sicurezza ha finanziato il progetto pilota, il prodotto possedeva l'interfaccia utente, l'IT possedeva l'IDP, il team frodi possedeva lo step-up e nessuno possedeva la spinta verso la coorte che in realtà guida l'iscrizione. Il programma si è mosso alla velocità del proprietario più lento.

Il FIDO Alliance 2024 Online Authentication Barometer ha rilevato che la familiarità con le passkey è salita al 57% a livello globale e il 42% degli intervistati che conoscono le passkey le ha abilitate su almeno un account. Il divario tra consapevolezza e abilitazione è il punto in cui l'ambiguità della proprietà del CIAM si manifesta più concretamente: la tecnologia funziona, il rollout no. Come ha affermato l'analista di Gartner David Mahdi nel contesto della convergenza delle discipline IAM, "le organizzazioni devono ripensare la propria architettura IAM per affrontare la crescente decentralizzazione della gestione delle identità e degli accessi". Senza un proprietario, il ripensamento non avviene.

2.3 Il problema delle analisi disconnesse#

Uno dei motivi per cui così tanti team finiscono per avere una partecipazione nel CIAM è che non esiste, per cominciare, uno strumento di analisi dell'autenticazione condiviso. Il diagramma sottostante mostra il modello: quattro sistemi contengono quattro sezioni del percorso di autenticazione e nulla si pone al di sopra di essi per unire i segnali.

Le linee guida sull'identità digitale della NIST Special Publication 800-63-4 richiedono esplicitamente una "valutazione continua" della garanzia dell'autenticatore, cosa impossibile senza una visione end-to-end degli eventi. In pratica, solo una minoranza di programmi B2C ha questa visione: il 2024 Ping Identity Consumer Survey ha rilevato che il 63% dei consumatori abbandonerebbe un account dopo due tentativi di accesso non validi; si tratta di una metrica che pochi team CIAM monitorano, perché i dati necessari si trovano in tre sistemi diversi.

Ogni proprietario protegge quindi la propria sezione. In parte è una questione di budget: il team che ha pagato per i dati ritiene di averne guadagnato il controllo. In parte è una leva: i dati sono il modo più semplice per dimostrare valore in una revisione interfunzionale. L'effetto pratico è che, anche quando un problema del CIAM abbraccia tutti e quattro i sistemi, nessuna singola persona può vederlo nella sua interezza. Un livello dedicato di osservabilità dell'autenticazione rimuove quella scusa e di solito innesca la conversazione sulla proprietà che era attesa da tempo.

3. Proprietari comuni#

Cinque funzioni rivendicano regolarmente diritti sul CIAM e ciascuna ottimizza per una metrica diversa. Il confronto sottostante riassume in base a cosa viene misurato ciascun archetipo e dove si trova il suo punto cieco.

3.1 Ufficio del CISO#

Ottimizza per: tasso di frode, copertura MFA, tasso di account compromessi e risultati degli audit. Tratta il CIAM come un controllo di sicurezza. Punti di forza: KPI chiari e autorità sul budget sotto pressione normativa (DORA, NIS2 o NIST 800-63). Punti ciechi: impatto dell'attrito sulla conversione, costi di supporto per flussi interrotti e l'esperienza della "coda lunga" di utenti i cui dispositivi si guastano in silenzio.

3.2 Ufficio del CTO#

Ottimizza per: sforzo di integrazione, affidabilità della piattaforma, qualità degli SDK, velocità di rilascio e costi di ingegneria. Tratta il CIAM come un problema di integrazione del prodotto, perché l'accesso è codice rilasciato assieme ad app, sito web e API. Punti di forza: vicinanza al prodotto, proprietà dell'SDK lato client, capacità di riparare rapidamente flussi interrotti. Punti ciechi: sfumature normative, compromessi in ambito di frode e igiene a lungo termine delle credenziali una volta che l'integrazione è live. Il CIO ricopre questo ruolo nel settore pubblico e nelle aziende con IT fortemente centralizzato, ma nella maggior parte delle aziende rivolte ai consumatori, l'ufficio del CTO è l'adattamento migliore.

3.3 Ufficio del CPO o del prodotto#

Ottimizza per: conversione del login, tasso di attivazione, successo del recupero e tempo necessario per ottenere il primo valore. Tratta il CIAM come un prodotto. Punti di forza: rigore nella UX, test A/B ed empatia con il cliente. Punti ciechi: esposizione alle frodi, vincoli normativi e igiene a lungo termine delle credenziali.

3.4 Ufficio frodi o rischi#

Ottimizza per: tasso di attivazione dello step-up, tasso di falsi positivi, tasso di storno di addebito (chargeback) e tasso di acquisizione degli account. Possiede un segmento dell'identità, raramente la sua totalità. Punti di forza: modellazione del rischio, segnali in tempo reale e risposta agli incidenti. Punti ciechi: flussi di iscrizione, flussi di recupero e le parti dell'identità che non sono transazionali.

3.5 Ufficio di crescita o marketing#

Proprietario emergente, in particolare negli abbonamenti per i consumatori e nel retail. Ottimizza per: tasso di re-engagement, login limitati dal cross-selling e prontezza per la personalizzazione. Tratta l'identità come il substrato per i cicli di crescita. Punti di forza: pensiero sul ciclo di vita e cultura della sperimentazione. Punti ciechi: tutto ciò che non riguarda la crescita.

4. Dove la proprietà divisa fa davvero male#

4.1 Provisioning contro deprovisioning#

Il provisioning è un problema di efficienza: quanto velocemente riesci a inserire un utente nel sistema. Il deprovisioning è un problema di sicurezza: quanto velocemente riesci a escludere un utente compromesso o non più in azienda. Vengono quasi sempre acquistati come uno strumento unico e sottocalibrati, perché il proprietario focalizzato sull'efficienza non percepisce mai il disagio del deprovisioning e il proprietario focalizzato sulla sicurezza non percepisce mai il disagio del provisioning.

4.2 UX di proprietà del team frodi rispetto a UX di proprietà del prodotto#

Il team frodi aggiunge attrito perché l'attrito blocca i malintenzionati. Il prodotto rimuove l'attrito perché l'attrito blocca i ricavi. Quando entrambi i team delineano la stessa pagina di accesso senza un proprietario condiviso, il risultato è un compromesso che non soddisfa nessuno: abbastanza attrito da infastidire gli utenti, ma non abbastanza per fermare le frodi. Uno step-up basato su un punteggio di rischio è la risposta tecnica. Un singolo proprietario del percorso è la risposta organizzativa.

4.3 Nessuna visione condivisa sulle prestazioni del login#

La divisione della proprietà causa danni anche perché non esiste un livello di analisi condiviso. I veri numeri sulle prestazioni di login (percentuale di successo complessiva, successo del recupero, tasso di attivazione dello step-up, quota di fallback per coorte e successo a livello di metodo, per es. password, OTP, social, passkey) sono sparsi tra IDP, suite di analisi del prodotto, motore frodi, SIEM e alcuni fogli di calcolo nel mezzo. Ogni team vede la propria porzione, nessuno vede l'intero percorso e i sintomi vengono sepolti all'interno di metriche che singolarmente sembrano a posto, ma nascondono il problema effettivo.

Un login lento per gli utenti su versioni di Android precedenti appare come un lieve picco nella latenza dell'IDP, un leggero calo nella conversione e un piccolo aumento nei ticket di supporto. Nessuno di questi è di per sé allarmante. Insieme, rappresentano una regressione che vale la pena correggere. Senza un proprietario e una visione unificata, tale regressione può rimanere intatta per trimestri.

5. Il settore plasma la risposta#

Il proprietario ultimo dell'identità del cliente e del consumatore dipende anche dal settore. Lo stesso organigramma che funziona per un settore viene considerato sovra- o sotto-governato in un altro.

• L'e-commerce tratta il CIAM come un problema di conversione. Il prodotto possiede il login, il growth possiede il re-engagement e le frodi affiancano entrambi. La propensione per la sicurezza è moderata. La cadenza prevede esperimenti settimanali. La ricerca sull'abbandono del carrello del Baymard Institute riporta un tasso di abbandono medio del 70,2% e una quota significativa è attribuibile all'attrito in fase di creazione dell'account, il che mantiene il prodotto saldamente al posto di guida.
• Il settore bancario e i servizi finanziari trattano il CIAM come un problema di sicurezza e conformità. Il CISO possiede il programma, il rischio possiede lo step-up e l'IT gestisce la piattaforma. La propensione alla sicurezza è elevata e la cadenza è trimestrale con rigorosi audit.
• Telco, assicurazioni e settore sanitario si collocano nel mezzo. La pressione della conformità li spinge verso il settore bancario. La pressione sull'esperienza del cliente li spinge verso l'e-commerce. Il modello di governance è solitamente suddiviso tra CISO e CPO con una scorecard condivisa.
• Il settore pubblico e il B2B regolamentato privilegiano la verificabilità rispetto alla sperimentazione. Il CIAM si colloca sotto il CIO (dove l'IT centralizzato esiste ancora) o sotto una funzione dedicata di governance dell'identità con una cadenza guidata dalla conformità. I requisiti del NIST 800-63-4 Identity Assurance Level stabiliscono lo standard minimo.

Il quadrante sottostante posiziona ciascun settore in base alle due dimensioni che guidano la risposta in termini di proprietà (propensione alla sicurezza e cadenza di revisione) e traccia il proprietario predominante derivante da ciascuna posizione.

Una scorecard che funziona per un rivenditore al dettaglio è considerata sotto-governata in una banca. Un modello di governance che funziona in una banca risulta eccessivamente ingegnerizzato per un rivenditore. Gli studi di Forrester sull'Impatto Economico Totale (TEI) del CIAM, commissionati dai fornitori, mostrano una gamma molto ampia di scenari: lo studio TEI di ForgeRock riportava un ROI del 186% su tre anni, mentre lo studio TEI di WSO2 riportava un ROI del 332%. Il mix di elementi trainanti (incremento delle conversioni rispetto alla riduzione delle frodi rispetto ai costi di audit) varia in modo significativo tra i diversi settori, motivo per cui l'intervallo di ROI stesso varia. La scelta del proprietario giusto inizia dall'identificazione del modello di settore in cui si opera effettivamente.

6. Identità per la forza lavoro e identità del cliente a confronto#

L'IAM per la forza lavoro e l'IAM per i clienti di solito risiedono in team diversi, ed è quasi sempre l'impostazione corretta. Entrambi riguardano l'identità, ma ottimizzano per obiettivi diversi. L'IAM per la forza lavoro gestisce i dipendenti noti su dispositivi gestiti con una sessione prolungata e un nucleo di utenti ristretto, in genere da 1.000 a 100.000 utenti. Il CIAM gestisce prospect e clienti anonimi su dispositivi non gestiti, con sessioni brevi sensibili alla conversione e un nucleo di utenti molto più vasto, spesso decine o centinaia di milioni. I modelli di minaccia, i KPI e le scelte degli strumenti divergono.

7. Nessuna singola risposta corretta#

Non esiste una collocazione universalmente giusta o sbagliata per il CIAM. Ciò che conta è che le dipendenze interne funzionino: il team proprietario ha l'autorità per prendere decisioni, i team che contribuiscono hanno un posto formale al tavolo e la scorecard è sufficientemente condivisa in modo che nessuno possa estrapolare una metrica fuori dal suo contesto.

Una banca regolamentata può gestire il CIAM sotto la direzione del CISO e avere successo. Un rivenditore può gestirlo sotto la direzione del CPO e avere successo. Una telco può operare con un modello suddiviso tra CISO e CPO e avere successo. Ciò che fallisce ovunque è la proprietà implicita senza una funzione di spinta, senza un livello di analisi condiviso e senza una cadenza per la revisione interfunzionale. Il modello organizzativo conta meno del modello operativo che vi si pone al di sopra.

8. Scorecard CIAM condivisa#

Scegliere una scorecard è di solito più semplice che scegliere un proprietario, e funziona senza riorganizzazioni. L'idea è semplice: la dashboard di ciascun dirigente è localmente corretta e globalmente incompleta. La soluzione è un'unica pagina, con cinque metriche, rivista mensilmente dalle funzioni proprietarie.

8.1 Metriche che nessuno possiede appieno#

Questi sono i cinque KPI interfunzionali che si collocano tra i punti di vista del CISO, CTO, CPO, team frodi e team growth. Ognuno è fondamentale e ciascuno di essi è sotto-monitorato nella maggior parte delle aziende. Il diagramma qui sotto mostra come ogni metrica si trovi all'intersezione tra più funzioni proprietarie, il che spiega perché nessuna di esse ricade in maniera esclusiva su un singolo team.

• Tasso di successo del login per coorte. Il successo del login a livello aggregato nasconde ogni cosa. Un tasso globale del 92% può mascherare un tasso del 70% per una specifica combinazione di sistema operativo, browser e gestore di credenziali. Riportare il tasso di successo solo a livello aggregato è l'errore di misurazione del CIAM più comune in assoluto.
• Tempo prima della prima azione autenticata. La latenza che l'utente sperimenta effettivamente dall'arrivo sulla pagina di login alla possibilità di effettuare transazioni. Include il tempo di attivazione della Conditional UI, la selezione delle credenziali, la richiesta biometrica e il reindirizzamento per il ritorno. È correlato alla conversione e nessuno lo possiede.
• Uso e successo del percorso di recupero. Quanti utenti tentano il recupero, quali percorsi utilizzano e quanti riescono nell'intento. Il recupero è il momento in cui le frodi incontrano l'attrito e i costi di supporto. Appartiene al CISO, al CPO e al CTO contemporaneamente, il che di solito significa che non appartiene a nessuno.
• Creazione delle passkey rispetto al loro utilizzo. La creazione è la quota di utenti idonei che si sono iscritti. L'uso è la quota di login che utilizza effettivamente una passkey. Un'implementazione può avere una copertura del 60% e un utilizzo del 20% se gli utenti iscritti continuano a digitare le password per abitudine. Lo stesso divario vale per qualsiasi nuovo metodo di autenticazione.
• Abbandono in base al metodo di autenticazione. Con quale metodo è iniziata la sessione e quanto spesso non è stata completata. L'abbandono di password, OTP, accessi social e passkey hanno cause profonde diverse: igiene delle credenziali, errore di recapito, interruzione di servizi terzi, posizionamento nell'interfaccia utente o conflitti col gestore di credenziali. Fare la media nasconde tutte queste problematiche.

8.2 Una pagina, cinque metriche, revisione mensile#

La scorecard è un documento di una sola pagina rivisto mensilmente dai proprietari, in modo congiunto. Ogni metrica ha un proprietario primario responsabile per la qualità dei dati, un proprietario interfunzionale per il piano d'azione e un obiettivo stabilito insieme all'inizio di ogni trimestre. Una pagina di Notion o un foglio di Google sono sufficienti: la revisione avviene sul documento riepilogativo, non sulle dashboard sottostanti.

Ogni proprietario contribuisce con la parte che solo lui può vedere:

• La Sicurezza contribuisce con il tasso di frode, il tasso di account compromessi e i risultati degli step-up per coorte.
• Il CTO / Ingegneria contribuisce con il tempo di attività (uptime), il tasso di errori di integrazione, le prestazioni dell'SDK e il costo per autenticazione suddiviso per metodo.
• Il Prodotto contribuisce con gli imbuti (funnel) di conversione, l'abbandono in ogni fase e il tempo prima di ottenere il primo valore.
• Le Frodi contribuiscono con il tasso di attivazione dello step-up e il tasso di falsi positivi per coorte.
• Il Growth contribuisce con il rapporto tra sessioni anonime e identificate, e il tasso di re-engagement.

La matrice seguente riassume il modello di contribuzione e rende evidenti i vuoti di copertura: nessun singolo proprietario produce da solo tutte e cinque le metriche.

8.3 Implementazione senza una riorganizzazione#

La maggior parte dei programmi di scorecard fallisce nella strumentazione (monitoraggio), non nella governance. Se il livello di osservabilità sottostante non è in grado di suddividere il tasso di successo in base al sistema operativo, al browser e al gestore di credenziali, nessuna cadenza di revisione produrrà una scorecard utile. La sequenza che funziona nella pratica è la seguente:

1. Prima la strumentazione. La telemetria degli eventi lato client, in grado di suddividere il tasso di successo per coorte, è il prerequisito per ogni altra metrica della scorecard.
2. Scegliere prima una metrica da co-gestire. Il tasso di successo del login per coorte è in genere la prima scelta giusta, poiché forza la strumentazione trasversale alle coorti da cui dipendono tutte le altre metriche.
3. Revisione mensile di 60 minuti. Primo incontro: accordo sulle cinque metriche e sulla situazione di base. Secondo incontro: accordo sugli obiettivi trimestrali. Terzo incontro: primo piano d'azione. Aggiungi metriche nel corso di due trimestri, invece che tutte in una volta.

A sei mesi, un'implementazione matura riporta il tasso di successo del login per coorte con proprietari designati per le tre peggiori, la copertura e l'uso delle passkey come due numeri distinti, il successo dei recuperi con un proprietario congiunto CISO/CPO, il tasso di attivazione dello step-up assieme al tasso di falsi positivi, e il costo per autenticazione suddiviso per metodo. La revisione mensile passa dal dibattito sui dati a quello sulle decisioni, che è il vero obiettivo finale.

9. In che modo Corbado aggiunge il livello di dati mancante per l'autenticazione#

Corbado non decide chi debba possedere il CIAM e non cerca di farlo. La proprietà è una decisione organizzativa. Ciò che Corbado offre è il livello di dati che mancava fin dal principio: il livello che silos, budget divisi e atteggiamenti del tipo "non è un mio problema" non hanno mai prodotto in autonomia. L'autenticazione dispone finalmente dell'equivalente di ciò che le analisi di prodotto, l'osservabilità e gli strumenti antifrode hanno già nei rispettivi domini.

Il livello di osservabilità dell'autenticazione si pone sopra all'IDP, al motore delle frodi e al SIEM e unisce i loro segnali in un'unica vista del percorso di login. I tentativi di backend, le azioni lato client, il comportamento dei gestori di credenziali, il successo a livello di coorte e i risultati dei recuperi risiedono in un unico sistema e vengono confrontati l'uno con l'altro.

• Un unico livello di dati per l'autenticazione. I segnali del backend, del frontend, delle frodi e della sicurezza sono correlati per sessione, per coorte e per percorso, cosicché le prestazioni reali del login smettano di essere sepolte in quattro sistemi separati.
• Tasso di successo a livello di coorte. Successo del login suddiviso per sistema operativo, browser, gestore di credenziali e hardware: è la prima metrica della scorecard che la maggior parte dei team non riesce a produrre con i propri strumenti esistenti.
• Creazione e utilizzo come numeri separati. La creazione delle passkey e l'utilizzo delle passkey vengono riportati come due KPI distinti, il che rappresenta la singola correzione di misurazione più importante di cui la maggior parte delle scorecard necessita.
• Analisi del percorso di recupero. L'utilizzo del flusso di recupero, il successo e l'abbandono emergono nella stessa classificazione di eventi dei flussi di login, permettendo a CISO e CPO di vedere gli stessi numeri.
• Abbandono per metodo. L'abbandono suddiviso per metodo consente alla scorecard di separare l'abbandono delle password (igiene delle credenziali) da quello delle passkey (conflitti dell'interfaccia utente o col gestore di credenziali).
• Misure di sicurezza del rollout. La soppressione dinamica, i "nudge" specifici per le coorti e i "kill-switch" consentono a chiunque stia gestendo il programma di apportare modifiche senza toccare direttamente l'IDP.
• Benchmark di riferimento. Le basi di partenza per il confronto tra diverse implementazioni tratte dalla base clienti di Corbado permettono di confrontare i numeri interni con quelli esterni, cosa che spesso trasforma una revisione mensile in una vera e propria decisione.

I disaccordi sulla proprietà non spariscono con un livello di dati. Diventano tuttavia più facili da risolvere, perché terminano le discussioni basate su "i miei dati dicono che" e iniziano quelle su cosa bisogna fare.

10. Conclusione#

Il CIAM ha più proprietari legittimi e questo non cambierà. Ciò che cambia è se l'azienda sceglie un proprietario o sceglie una scorecard. Scegliere un proprietario è più rapido ma richiede capitale politico. Scegliere una scorecard è più lento ma funziona senza una riorganizzazione aziendale. Entrambi i percorsi sono migliori del lancio della moneta implicito a cui la maggior parte delle aziende si affida oggi. Il costo di una proprietà ambigua si misura in rollout bloccati, flussi frammentati e l'erosione silenziosa sia dei numeri relativi alla sicurezza, sia di quelli relativi alla conversione allo stesso tempo.

Chi siamo

Corbado è la Passkey Intelligence Platform per i team CIAM che gestiscono l'autenticazione consumer su larga scala. Ti aiutiamo a vedere ciò che i log IDP e gli strumenti di analytics generici non mostrano: quali dispositivi, versioni di OS, browser e gestori di credenziali supportano i passkey, perché gli enrollment non si trasformano in login, dove il flusso WebAuthn fallisce e quando un aggiornamento di OS o browser interrompe silenziosamente il login — tutto senza sostituire Okta, Auth0, Ping, Cognito o il tuo IDP interno. Due prodotti: Corbado Observe aggiunge osservabilità per i passkey e qualsiasi altro metodo di login. Corbado Connect introduce passkey gestiti con analytics integrato (insieme al tuo IDP). VicRoads gestisce i passkey per oltre 5M di utenti con Corbado (+80 % di attivazione passkey). Parla con un esperto di Passkey →

FAQ#

Chi possiede tipicamente il CIAM in una grande azienda?#

Nella nostra esperienza, la proprietà è divisa tra le funzioni CISO, CTO, CPO, frodi e growth. Nei settori regolamentati, l'ufficio del CISO detiene l'autorità principale. Nelle aziende guidate dai consumatori e di natura nativamente digitale, l'ufficio del CPO o del CTO detiene solitamente l'autorità primaria, perché il CIAM deve essere integrato nel prodotto. Un product manager dedicato all'identità che gestisce una scorecard condivisa è il modello maturo in entrambi i casi.

Il settore di appartenenza cambia chi dovrebbe possedere il CIAM?#

Sì. L'e-commerce tratta il CIAM come un problema di conversione e di solito ricade sul prodotto o sulla crescita (growth). Il settore bancario lo tratta come un problema di sicurezza e conformità e ricade sul CISO. Telco, assicurazioni e sanità utilizzano modelli divisi. La risposta giusta segue la propensione alla sicurezza e la cadenza di revisione del settore, e non una best practice astratta.

Perché la proprietà divisa del CIAM danneggia i nuovi rollout di autenticazione?#

Qualsiasi nuovo metodo di autenticazione (dai login social, allo step-up MFA, fino alle passkey) necessita di un coordinamento della UX di iscrizione, di flussi di recupero, politiche di rischio e strumenti di supporto. Quando ognuno di essi è gestito da un proprietario diverso con velocità diverse, il rollout avanza alla velocità del proprietario più lento. Le implementazioni di passkey ne sono l'esempio attuale più visibile e regolarmente si fermano al 5%-15% di adozione.

L'IAM per la forza lavoro e l'IAM per i clienti dovrebbero risiedere nello stesso team?#

Di solito no. Condividono il vocabolario, ma poco altro. L'IAM per la forza lavoro ottimizza per dispositivi gestiti, utenti noti ed efficienza dei costi. Il CIAM ottimizza per dispositivi non gestiti, utenti anonimi e conversione. La maggior parte delle aziende mature li mantiene sotto una governance separata, condividendo un consiglio direttivo piuttosto che un singolo leader.

Quali sono i KPI più importanti del CIAM?#

Cinque metriche interfunzionali che si collocano a cavallo tra le dashboard di ciascuna funzione: tasso di successo del login per coorte, tempo prima della prima azione autenticata, copertura e utilizzo delle passkey intesi come due numeri distinti, successo del percorso di recupero e abbandono per metodo di autenticazione. Ognuno di essi è fondamentale e risulta carente in termini di strumentazione nella maggior parte delle aziende.

Perché la copertura delle passkey e l'utilizzo delle passkey non sono la stessa metrica?#

La copertura (reach) è la percentuale di utenti idonei che hanno registrato una passkey. L'utilizzo (usage) è la percentuale di login in cui viene effettivamente usata una passkey. Un'implementazione può avere un'elevata copertura e un basso utilizzo se gli utenti registrati continuano a digitare le password per abitudine. Segnalare solo una metrica trae in inganno la revisione dirigenziale.

Che cos'è una scorecard CIAM condivisa?#

Un documento di una sola pagina con cinque metriche interfunzionali, rivisto mensilmente dai team proprietari in modo congiunto. Ogni metrica ha un proprietario primario per la qualità dei dati, un proprietario interfunzionale per il piano d'azione e un obiettivo stabilito in accordo all'inizio di ogni trimestre. La revisione avviene su questa singola pagina e non sulle dashboard sottostanti.

Quanto spesso dovrebbe essere esaminata la scorecard?#

Mensilmente, in una riunione interfunzionale di 60 minuti con le funzioni proprietarie. Se avviene più di frequente, non cambia nulla tra una revisione e l'altra. Se avviene meno di frequente, le derive sistemiche passano inosservate, in particolar modo le regressioni a livello di coorte successive ad aggiornamenti del sistema operativo o del browser.

Come possiamo iniziare senza attuare una riorganizzazione?#

Scegli le due metriche che fanno più male, organizza una revisione mensile di 60 minuti con i proprietari unicamente per queste metriche e amplia il monitoraggio nel corso di due trimestri. Nessun titolo cambierà. La scorecard stessa diventerà il livello di governance. La maggior parte delle aziende raggiunge un modello maturo tra i 12 e i 18 mesi senza mai modificare formalmente le linee di riporto.

Un fornitore può aiutare a risolvere le controversie sulla proprietà?#

Un fornitore non può decidere la proprietà al tuo posto. Può rimuovere l'ambiguità sui dati che rende le controversie sulla proprietà più difficili da risolvere. Un livello di analisi condiviso fornisce a ciascun proprietario la sezione di suo interesse, mantenendo però la vista aggregata, il che spesso è sufficiente per trasformare un dibattito politico in un dibattito operativo.