Financial assets secondo EN 18031-3: cosa sono e come identificarli
Se stai leggendo EN 18031-3 perché produci (o integri) radio equipment con funzioni di pagamento, wallet, banking, trading, o anche "solo" autorizzazioni di transazioni via app/dispositivo, prima o poi ti imbatterai nel concetto di financial asset.
3 marzo 2026
Introduzione
Se stai leggendo EN 18031-3 perché produci (o integri) radio equipment con funzioni di pagamento, wallet, banking, trading, o anche "solo" autorizzazioni di transazioni via app/dispositivo, prima o poi ti imbatterai nel concetto di financial asset.
È una scelta precisa della norma: invece di dire "proteggi i pagamenti", EN 18031 ragiona per asset, minacce, meccanismi, evidenze e test.
L'idea chiave è semplice: un attaccante non deve per forza "rubare soldi" direttamente. Spesso gli basta ottenere (o alterare) dati e configurazioni che permettono di commettere frode. Per questo EN 18031-3 definisce "financial asset" in modo volutamente ampio, includendo non solo dati, ma anche funzioni e configurazioni.
Se ti sei trovato a leggere la normativa EN 18031-3, magari perché produci o integri dispositivi radio con funzioni di pagamento, wallet, banking, trading, o anche "solo" per autorizzare transazioni da app, prima o poi ti sei scontrato con il termine financial asset.
La norma ha una logica ben precisa e serve per assicurarsi che chi produca dispositivi che effettuino transazioni, lanci sul mercato dei prodotti che tutelino i suoi clienti.
Il concetto di fondo è abbastanza semplice e preoccupante: un attaccante non ha per forza bisogno di "rubare soldi" nel senso classico del termine. Spesso gli basta mettere le mani su certi dati o modificare alcune configurazioni per aprire la strada a una frode.
Gli asset finanziari sono una delle quattro famiglie di asset definite dalla EN 18031. Per il contesto su come si relazionano alle altre tre, consulta la nostra panoramica degli asset EN 18031.
Cosa sono i financial assets
La normativa EN 18031-3 definisce financial asset come l'insieme di sensitive financial data, confidential financial data,sensitive financial function configuration, confidential financial function configuration e le financial functions stesse.
Questa frase, da sola, ti dice già due cose importanti:
non si parla solo di "dati"
la norma distingue tra aspetti "sensitive" e "confidential" perché il rischio non è solo la divulgazione, ma anche la manipolazione.
Per completare il quadro, la norma definisce anche:
financial data: dati che rappresentano, forniscono informazioni su, o sono processati per trasferire money/monetary assets/virtual currencies.
financial function: funzionalità dell'equipment che processa financial data.
financial function configuration: dati processati dall'equipment che definiscono il comportamento delle financial functions.
Facciamo qualche esempio
Qui conviene ragionare per categorie, seguendo la struttura della definizione della normativa.
Financial data
Nel linguaggio della norma, financial data è qualsiasi dato che:
rappresenta valore
descrive valore
oppure è processato per trasferire valore.
Esempi tipici:
dettagli di una transazione: importo, beneficiario, riferimenti, metadata
dati che identificano conti o strumenti: IBAN, riferimenti di account, alias beneficiario
nel caso crypto: indirizzi wallet, payload di transazione, parametri usati per firma/autorizzazione
token o riferimenti che abilitano un pagamento o una disposizione (attenzione a dove vengono loggati o tracciati)
La regola pratica è che se quel dato, da solo o insieme ad altri, rende possibile una frode o un trasferimento indebito, allora è financial data (e quindi potenzialmente un financial asset).
Financial function configuration
Qui cadono cose che spesso i team sottovalutano:
limiti e soglie (massimali giornalieri, importo massimo)
whitelist/blacklist beneficiari
regole di autorizzazione: quando serve MFA, OTP, firma forte
parametri di "routing": endpoint backend, certificati/chiavi usati per validazione, pinning, ecc.
Se qualcuno riesce a leggere o alterare queste configurazioni, può trasformare una funzione corretta in una funzione "fraud-friendly". Ed è esattamente per questo che EN 18031-3 le include nei financial assets.
Financial functions (le funzioni)
Le funzioni finanziarie riguarda l'operatività, come inviare, approvare, firmare, abilitare.
Ecco alcuni esempi:
invio di denaro, approvazione pagamento, firma transazione
gestione beneficiari (aggiungi/modifica), impostazione limiti
funzioni di gestione wallet (dipende dal prodotto e dal perimetro)
Il senso è che se anche si proteggono bene i dati, se un hacker attacca una funzione finanziaria e questa non ha i controlli giusti, la frode può avvenire comunque.
Perché la norma usa il concetto di "asset"
La normativa EN 18031-3 dice che gli asset sono introdotti come "target" principali su cui applicare i requisiti e allineare i tre standard orizzontali della famiglia 18031.
C'è anche una tabella riassuntiva che collega le tipologie di asset agli essential requirements (e per EN 18031-3 è rilevante l'essential requirement 3.3.f).
Una delle frasi più utili e che fa capire bene il concetto principale di questa normativa è riassunta in questa frase:
> Proteggere un asset non significa solo proteggere "i dati", ma anche proteggere funzioni e configurazioni che li usano.
"Sensitive" vs "Confidential"
Dentro la definizione di financial asset si trovano le parole "confidential" e "sensitive", applicati sia ai dati sia alle configurazioni.
In generale, il modo più pratico è sapere che:
confidential: se la divulgazione dell'informazione abilita un danno (tipicamente frode)
sensitive: se la manipolazione dell'informazione abilita un danno (tipicamente frode)
Nel dominio finanziario la norma è particolarmente esplicita sul legame "confidential → disclosure → fraud", anche nelle definizioni (per financial data e per configuration).
Questa distinzione ti serve per classificare gli asset e decidere cosa testare.
Se l'asset è confidential, devi dimostrare protezioni di confidenzialità (e.g., prevenire leakage via log, storage, traffico).
Se l'asset è sensitive, devi dimostrare protezioni di integrità (e.g., prevenire manomissione di importo/beneficiario/configurazioni).
Lo stesso schema si applica agli asset di sicurezza - funzioni piu parametri. Consulta la nostra guida agli asset di sicurezza per la struttura parallela.
Come muoversi "bene" nella normativa: un set di passi realistico
Se dovessimo descrivere un approccio chiaro e che sia ripetibile, questi sono i punti principali:
Inventario: crea una lista completa dei financial assets, distinguendo bene dati, configurazioni e funzioni.
Classifica: marca per ogni asset se è soprattutto "confidential" (leak → frode) o "sensitive" (tamper → frode).
Data flow: disegna il flusso end-to-end della funzione finanziaria (client, backend, storage, log).
Meccanismi EN: per ogni punto del flusso e per ogni interfaccia esterna, aggancia i meccanismi di sicurezza pertinenti.
Evidenze: prepara la documentazione richiesta dalla norma (le "required information" per i meccanismi applicabili).
Test: trasforma gli assessment criteria in casi di test concreti (completeness e sufficiency inclusi).
Facciamo un esempio pratico di compilazione della tabella di Financial Assets
Ricodiamoci che i financial assets sono beni informativi o funzionali legati al denaro che il tuo dispositivo/app crea, elabora, memorizza o trasmette e che, se compromessi, possono causare perdita economica, frodi, addebiti non autorizzati, manomissione di importi/operazioni o accesso indebito a fondi/crediti.
Per compilare la tabella "Financial assets" bisogna pensare riga per riga, dove ognuna di questa descrive un singolo asset finanziario (dato o "oggetto" che abilita/condiziona un'operazione economica).
Come compilare campo per campo
1) asset_name (Financial Assets)
Qui devi dare un nome chiaro a questo dato. Ti conviene usare un nome univoco e descrittivo.
Ad esempio: `FA01PaymentToken`, `FA02TransactionData`, `FA03_Balance` (descrivi semplicemente "che cos'è").
Evita nomi generici tipo "Pagamento".
2) accessible_by_entity (Is it accessible by an entity?)
Questo campo chiede se qualche entità (utente, amministratore, servizio, app, sistema remoto) può leggere, usare o modificare l'asset tramite qualche canale (UI, API, SSH, file system, ecc.).
Rispondere:
Yes: se qualcuno può in qualche modo accedervi, gestirlo o usarlo.
No: se nessuno può accedervi (caso raro; sarebbe totalmente interno e inaccessibile).
3) persisted_on_device (Is persisted on the device?)
Chiede se l'asset è memorizzato in modo persistente sul dispositivo.
Yes: è salvato su storage (file, database, NVRAM, config) e resta dopo reboot.
No: esiste solo temporaneamente (in RAM o sessione) e sparisce al riavvio.
4) confidential (Sensitive or Confidential financial function configuration?)
Serve a distinguere "l'importanza" dell'asset:
Qui si deve scegliere tra:
Sensitive: se la compromissione può abilitare frode/addebiti/trasferimenti o permette di autorizzare o eseguire operazioni economiche, o rivela dati di pagamento ad alto impatto.
Esempi: payment token "charge", credenziali wallet, dati carta, chiavi/secret di firma transazioni, consensi/mandati di addebito.
Confidential: se è finanziario ma la sua divulgazione o manomissione è tipicamente meno "abilitante" rispetto a credenziali/token, pur avendo impatto economico o di privacy.
Esempi: storico transazioni con importi, listini/sconti, fatture/ordini (senza strumenti di autorizzazione).
Se si è indecisi, per compliance è più sicuro classificare Sensitive quando l'asset può essere usato per fare danni diretti (pagare, addebitare, trasferire, cambiare importi).
5) impacted_external_if (Potentially impacted via external interfaces?)
Qui si chiede se l'asset può essere letto o modificato tramite interfacce esterne (fisiche o locali) del device (USB, UART/seriale, HDMI in certe architetture, ecc.).
Yes: se da quelle interfacce puoi influenzarlo (es. estrarre config, cambiarla, fare debug con accesso ai file).
No: se quelle interfacce non danno modo realistico di impattarlo.
6) communicated_over_network_if (Is communicated over a network interface?)
Chiede se l'asset viene trasmesso in rete (anche solo come parte di un protocollo o scambio).
Yes: se passa su Ethernet/Wi‑Fi/Internet (es. token/cookie inviati, certificati scambiati, configurazioni scaricate).
No: non viene mai inviato su rete.
7) accessible_via_network_if (Is communicated via network interfaces?)
Questo campo serve per capire quanto il l'asset sia la "raggiungibile via rete" e se può esser esser accessibile o modificabile:
Yes: se l'asset è accessibile o modificabile via rete (WebUI/API/SSH/servizio esposto).
No: se via rete non lo puoi leggere/modificare (anche se magari il device lo usa internamente).
Se nel tuo sistema c'è un'API che riceve un importo, un ordine o un token, quasi sempre la risposta è "Yes".
8) crypto_used (Cryptography used to protect the asset)
Chiede se l'asset è protetto con crittografia:
in transito (es. TLS/SSH/VPN quando viene comunicato),
e/o a riposo (file cifrato, keystore, secret storage).
Yes: se c'è protezione crittografica.
No: seè in chiaro o senza protezioni crittografiche.
Nota: "hash" (es. password hash) spesso è protezione, ma non è "crittografia" in senso stretto; dipende da come volete interpretarlo nel progetto (possiamo allinearlo in modo consistente).
Procedura pratica e ripetibile per ogni riga
Per ogni asset (riga), fai questa mini-analisi e poi valorizza le colonne:
Definisci l'asset in una frase: "che cosa è e a cosa serve economicamente".
Dove compare nel ciclo di vita: creato da chi? usato da chi? inviato a chi?
Dove risiede: solo RAM / log / DB / secure element / cloud / app.
Quali interfacce lo toccano:
- esterne locali (USB/BLE/debug) → `impactedexternalif`
- rete (IP/Internet/API) → `communicatedovernetworkif` e `accessiblevianetworkif`
Quali protezioni: TLS? cifratura storage? firma? → `crypto_used`
Classifica confidenzialità: "abilita frode?" → Sensitive, altrimenti Confidential.
Come RedComply gestisce tutto il processo
Identificare i financial assets manualmente su un firmware è un lavoro da settimane: analisi del filesystem, scansioni di rete, revisione degli script di avvio, ricerca delle configurazioni sparse su directory non standard.
Fatto manualmente, richiede settimane.
Con la nostra piattaforma, ridurrai i tempi di compilazione di questa normativa di oltre il 90%!
Questo perchè RedComply automatizza le parti più pesanti del processo.
Analisi automatica
Caricate la documentazione del vostro progetto e, per ogni financial function e configuration identificata, la piattaforma:
Propone la classificazione sensibile/confidenziale
Segnala le versioni di librerie con CVE note
Identifica servizi esposti non documentati
Verifica la coerenza con i requisiti GEC-2, GEC-3 e GEC-4
Tracciamento delle versioni
A ogni aggiornamento firmware, RedComply confronta la nuova versione con la precedente e rileva:
Nuove financial functions introdotte
Configurazioni modificate o aggiunte
Nuovi servizi esposti
Variazioni nel profilo di conformità
Dove Iniziare
Dal 1° agosto 2025, la conformità RED è diventata obbligatoria per i dispositivi IoT con interfacce radio. I financial assets vanno identificati prima di poter valutare qualsiasi requisito di EN 18031-3.
RedComply velocizza di oltre il 90% il tempo di compilazione dei security e di tutta la normativa RED.
Caricate il firmware e ottenete una prima mappatura automatica dei financial assets in pochi giorni.
Richiedi una Demo e verrai contattato al più dal nostro team per aiutarti!
RedComply riduce i tempi di compliance EN 18031 di oltre il 90%. Scopri di più su redcomply.com.