P2PE, E2EE i NESA – 3 podejścia do szyfrowania płatności i ich wpływ na zakres PCI DSS

Czym różnią się P2PE, E2EE i NESA? P2PE (Point-to-Point Encryption) to szyfrowanie danych kartowych walidowane przez PCI SSC i wpisane na oficjalną listę rozwiązań. E2EE (End-to-End Encryption) to szyfrowanie o podobnej architekturze, ale bez walidacji PCI. NESA (Non-listed Encryption Solution Assessment) to ocena rozwiązania E2EE wykonana przez P2PE QSA według wymogów standardu P2PE, bez wpisu na listę PCI SSC.

Definicja kanoniczna: NESA (Non-listed Encryption Solution Assessment) to ocena niewalidowanego rozwiązania szyfrującego dane kartowe, wykonywana przez P2PE QSA według wymogów standardu PCI P2PE, dokumentująca luki względem standardu i wpływ rozwiązania na zakres PCI DSS merchanta.

Wybór między tymi trzema podejściami decyduje o tym, czy merchant wypełni SAQ P2PE z 21 pytaniami, czy będzie negocjował zakres z agentem rozliczeniowym, a dla dostawcy – o koszcie wejścia na rynek i sile argumentu sprzedażowego.

P2PE, E2EE i NESA – w skrócie:

1. Tylko rozwiązania walidowane i wpisane na listę PCI SSC dają merchantowi prawo do wypełnienia SAQ P2PE, który zawiera 21 pytań (SAQ P2PE v4.0, dokument PCI SSC).
2. E2EE technicznie może szyfrować dane identycznie jak P2PE, ale redukcja zakresu PCI DSS zależy wtedy wyłącznie od decyzji agenta rozliczeniowego (acquirera).
3. NESA nie jest certyfikacją ani wpisem na listę – to dokument opisujący luki rozwiązania względem standardu PCI P2PE, przygotowany przez P2PE QSA.
4. Aktualny standard PCI P2PE w wersji 3.2 (cze 2025) obejmuje 5 domen: od zarządzania urządzeniami POI, przez bezpieczeństwo aplikacji, po operacje na kluczach kryptograficznych.
5. Walidacja P2PE wymaga urządzeń POI zatwierdzonych w programie PCI PTS z funkcją SRED oraz HSM zgodnych z FIPS 140-2/140-3 poziom 3 lub PCI HSM w środowisku deszyfracji.
6. Patronusec jako akredytowany QSA doradza zarówno merchantom wybierającym rozwiązanie szyfrujące, jak i dostawcom przygotowującym się do walidacji P2PE lub oceny NESA.

---

---

Czym różni się P2PE od E2EE?

P2PE różni się od E2EE statusem formalnym, nie architekturą techniczną. P2PE to rozwiązanie zwalidowane przez P2PE QSA według standardu PCI P2PE i wpisane na listę PCI SSC. E2EE to każde szyfrowanie danych kartowych od punktu akceptacji do punktu deszyfracji, które takiej walidacji nie przeszło. Konsekwencje dotyczą zakresu PCI DSS merchanta i tego, kto o nim decyduje.

Oba podejścia realizują ten sam cel: dane karty są szyfrowane w momencie odczytu w terminalu i pozostają zaszyfrowane aż do bezpiecznego środowiska deszyfracji, dzięki czemu systemy merchanta nigdy nie mają kontaktu z danymi jawnymi. Różnica polega na tym, kto potwierdza, że rozwiązanie faktycznie działa tak, jak deklaruje dostawca.

W przypadku P2PE potwierdzeniem jest niezależna ocena wykonana przez P2PE QSA (Qualified Security Assessor z dodatkową kwalifikacją P2PE), raport P-ROV (P2PE Report on Validation) zaakceptowany przez PCI SSC oraz publiczny wpis na liście Validated P2PE Solutions. W przypadku E2EE takiego potwierdzenia nie ma – merchant i jego agent rozliczeniowy polegają na deklaracjach dostawcy lub na ocenie wykonanej we własnym zakresie.

Walidowane rozwiązanie P2PE to jedyna klasa rozwiązań szyfrujących, która automatycznie uprawnia merchanta do skorzystania z SAQ P2PE – dla rozwiązań E2EE każdą redukcję zakresu PCI DSS musi indywidualnie zaakceptować agent rozliczeniowy.

W praktyce oznacza to: jeżeli dwóch dostawców oferuje technicznie identyczne szyfrowanie, ale tylko jeden ma wpis na liście PCI SSC, merchant korzystający z rozwiązania wpisanego na listę ma z góry zagwarantowaną ścieżkę uproszczonej zgodności, a drugi musi ją każdorazowo negocjować.

Czym jest walidowane rozwiązanie P2PE i co daje merchantowi?

Walidowane rozwiązanie P2PE to kompletny zestaw sprzętu, oprogramowania i procesów, który szyfruje dane kartowe w zatwierdzonym urządzeniu POI i deszyfruje je dopiero w bezpiecznym środowisku dostawcy, oceniony według 5 domen standardu PCI P2PE i wpisany na listę PCI SSC. Merchant korzystający z takiego rozwiązania eliminuje dane jawne ze swojego środowiska.

Aktualny standard PCI P2PE v3.2 (cze 2025) wymaga, aby szyfrowanie odbywało się wyłącznie w urządzeniach POI zatwierdzonych w programie PCI PTS z aktywną funkcją SRED (Secure Reading and Exchange of Data), a deszyfracja i operacje na kluczach – w modułach HSM zgodnych z FIPS 140-2/140-3 poziom 3 lub wyższy albo zatwierdzonych według PCI HSM. Według PCI SSC wersja 3.2 to rewizja porządkująca: walidacje wykonane wg v3.0 i v3.1 zachowują ważność, a Rada równolegle rozwija P2PE v4.0. Kluczowym artefaktem dla merchanta jest PIM (P2PE Instruction Manual) – instrukcja opisująca, jak bezpiecznie eksploatować terminale.

Korzyści dla merchanta są mierzalne:

• SAQ P2PE zamiast SAQ D. Porównanie oficjalnych kwestionariuszy PCI SSC dla PCI DSS v3.2.1 pokazuje skalę: SAQ D liczył 329 pytań, a SAQ P2PE 33 – redukcja o blisko 90%. W wydaniu dla PCI DSS v4 (obecnie obowiązuje v4.0.1) SAQ P2PE skonsolidowano do 21 pytań.
• Brak wymogu skanów podatności i testów penetracyjnych w ramach SAQ P2PE – te obowiązki pozostają po stronie dostawcy rozwiązania w jego środowisku deszyfracji.
• Niższe ryzyko naruszenia. Skradzione dane zaszyfrowane w SRED nie mają wartości dla atakującego, bo klucze nigdy nie opuszczają urządzeń kryptograficznych.

Korzyść dla dostawcy jest inna, ale równie konkretna: wpis na listę PCI SSC to argument sprzedażowy, który skraca dyskusje o zgodności z każdym kolejnym merchantem i acquirerem. Zamiast indywidualnych ocen dostawca pokazuje jeden publiczny listing.

Patronusec Insight: Z naszego doświadczenia projektowego wynika, że merchanci najczęściej przepłacają nie za samo rozwiązanie szyfrujące, lecz za brak weryfikacji szczegółów listingu przed wdrożeniem. Lista PCI SSC precyzuje dokładne modele urządzeń POI, wersje aplikacji i konfiguracje objęte walidacją – wdrożenie terminala w wariancie spoza listingu (np. inna wersja firmware) wyklucza prawo do SAQ P2PE, mimo że merchant kupił „walidowane rozwiązanie”. Przed podpisaniem umowy z dostawcą warto porównać ofertę wdrożeniową z treścią listingu pozycja po pozycji.

Czym jest E2EE w płatnościach i jakie ma ograniczenia?

E2EE (End-to-End Encryption) w płatnościach to szyfrowanie danych kartowych od punktu interakcji do punktu deszyfracji u procesora lub dostawcy bramki, realizowane bez walidacji według standardu PCI P2PE. Rozwiązania E2EE oferuje wielu procesorów i dostawców terminali, często jako standardowy element usługi acquiringowej.

Techniczna jakość rozwiązań E2EE bywa wysoka – część z nich powstała, zanim PCI SSC opublikowała pierwszą wersję standardu P2PE (wrz 2011), i działa na rynku od lat. Problemem nie jest kryptografia, lecz brak niezależnego potwierdzenia trzech obszarów, które standard P2PE weryfikuje szczegółowo: zarządzania kluczami (generowanie, dystrybucja, wstrzykiwanie), łańcucha dostaw urządzeń oraz bezpieczeństwa środowiska deszyfracji.

Dla merchanta oznacza to dwie konsekwencje:

• Redukcja zakresu nie jest automatyczna. Merchant nie może wypełnić SAQ P2PE. O ewentualnym ograniczeniu stosowanych kontroli PCI DSS decyduje agent rozliczeniowy na podstawie własnej oceny ryzyka.
• Ciężar dowodu leży po stronie merchanta i dostawcy. QSA oceniający środowisko merchanta musi samodzielnie ustalić, dokąd sięga zakres PCI DSS, bo nie ma listingu, na którym mógłby się oprzeć.

Dla dostawcy E2EE ma jednak realne zalety biznesowe: brak kosztów walidacji (ocena P2PE to projekt liczony w miesiącach), swoboda zmian w rozwiązaniu bez procesu delta assessment oraz szybszy time-to-market. To uzasadniony wybór, gdy dostawca działa głównie z jednym acquirerem, który akceptuje jego rozwiązanie, albo gdy rozwiązanie dopiero dojrzewa do pełnej walidacji.

E2EE i P2PE mogą używać identycznych algorytmów i architektury – różnica polega na tym, że w P2PE zgodność każdego elementu rozwiązania z wymogami potwierdził niezależny P2PE QSA, a w E2EE potwierdzenia dokonuje (lub nie) agent rozliczeniowy.

Czym jest NESA i kiedy ma zastosowanie?

NESA (Non-listed Encryption Solution Assessment) to ocena niewalidowanego rozwiązania szyfrującego, którą P2PE QSA wykonuje według wymogów standardu PCI P2PE na podstawie wytycznych PCI SSC z 2016 r. Wynikiem jest dokumentacja luk względem standardu oraz rekomendacja, jak rozwiązanie wpływa na zakres PCI DSS merchanta. NESA nie kończy się wpisem na listę PCI SSC.

Zgodnie z FAQ PCI SSC celem NESA jest zidentyfikowanie różnic między rozwiązaniem a standardem PCI P2PE i pokazanie, jak korzystanie z rozwiązania wpływa na ocenę PCI DSS merchanta. Rada podkreśla, że to wyłącznie wytyczne (guidance), a nie wymagania, i że tylko rozwiązania wpisane na listę są w pełni zwalidowane według standardu.

Proces wygląda następująco: dostawca rozwiązania zleca ocenę P2PE QSA, który wypełnia szablon NESA oraz raport P-ROV. Komplet dokumentów trafia do merchantów korzystających z rozwiązania, a ci przekazują go swoim QSA jako materiał wejściowy do oceny PCI DSS. Według PCI Perspectives (blog PCI SSC) NESA powstała z myślą o sytuacjach, w których merchant używa rozwiązania szyfrującego starszego niż standard P2PE.

Kluczowe ograniczenia NESA:

• Merchant nadal nie może wypełnić SAQ P2PE – kryteria kwalifikacji do SAQ pozostają bez zmian.
• Redukcję zakresu musi zaakceptować acquirer merchanta – NESA jest argumentem, nie decyzją.
• NESA opisuje stan na moment oceny; bez programu nadzoru PCI SSC nie ma mechanizmu wymuszającego utrzymanie zgodności.

W praktyce rynkowej NESA pełni często rolę etapu przejściowego dla dostawców zmierzających do pełnej walidacji P2PE: pozwala wcześniej dać merchantom udokumentowany argument w rozmowach z acquirerami. To także sposób na urealnienie kosztów: NESA pokazuje, ile brakuje do pełnej zgodności, zanim dostawca zainwestuje w formalny program walidacji.

Jakie korzyści daje każdy typ rozwiązania dostawcy, a jakie merchantowi?

Każde z trzech podejść inaczej rozkłada koszty i korzyści między dostawcę a merchanta. P2PE maksymalizuje korzyść merchanta kosztem inwestycji dostawcy, E2EE minimalizuje koszty dostawcy kosztem niepewności merchanta, a NESA plasuje się pośrodku.

Kryterium	P2PE (walidowane)	NESA	E2EE (bez oceny)
Wpis na listę PCI SSC	Tak	Nie	Nie
SAQ dla merchanta	SAQ P2PE (21 pytań w v4.0)	SAQ ustalany z acquirerem	SAQ ustalany z acquirerem (zwykle SAQ D lub B-IP)
Kto decyduje o redukcji zakresu	PCI SSC (przez listing) + acquirer formalnie	Acquirer na podstawie dokumentu NESA	Acquirer na podstawie deklaracji dostawcy
Ocena wykonywana przez	P2PE QSA (pełny P-ROV, akceptacja PCI SSC)	P2PE QSA (NESA + P-ROV, bez akceptacji PCI SSC)	Brak wymogu formalnej oceny
Cykl utrzymania	3-letnia rewalidacja + roczne potwierdzenie statusu	Brak formalnego cyklu	Brak
Korzyść główna dostawcy	Argument sprzedażowy dla każdego acquirera i merchanta	Udokumentowana dojrzałość, etap do pełnej walidacji	Niski koszt, szybki time-to-market
Korzyść główna merchanta	Minimalny zakres PCI DSS, brak skanów i pentestów w SAQ	Możliwa redukcja zakresu po akceptacji acquirera	Realne obniżenie ryzyka technicznego bez gwarancji formalnych

Dla dostawcy rozwiązania decyzja sprowadza się do modelu biznesowego. Jeżeli rozwiązanie ma być sprzedawane wielu merchantom współpracującym z różnymi acquirerami, walidacja P2PE zwraca się przez eliminację indywidualnych negocjacji. Jeżeli dostawca obsługuje zamknięty ekosystem jednego acquirera, E2EE z dobrą dokumentacją może wystarczyć.

W praktyce oznacza to: pytanie „P2PE czy E2EE” jest w istocie pytaniem „kto ma ponieść koszt dowodu bezpieczeństwa – dostawca raz, czy każdy merchant osobno”.

Jak wybrać między P2PE, E2EE i NESA?

Wybór zależy od trzech zmiennych: liczby acquirerów w ekosystemie, dojrzałości rozwiązania względem standardu P2PE oraz tego, czy redukcja zakresu PCI DSS jest elementem oferty. Poniższe drzewo decyzyjne porządkuje najczęstsze scenariusze.

Perspektywa merchanta:

1. Czy rozwiązanie jest na liście Validated P2PE Solutions PCI SSC (w konfiguracji, którą wdrażasz)?
   • TAK → kwalifikujesz się do SAQ P2PE. Zweryfikuj zgodność wdrożenia z listingiem i stosuj PIM.
   • NIE → przejdź do pytania 2.
2. Czy dostawca dysponuje aktualnym dokumentem NESA od P2PE QSA?
   • TAK → przekaż NESA swojemu QSA i acquirerowi; negocjuj zredukowany zestaw kontroli. SAQ P2PE pozostaje niedostępny.
   • NIE → przejdź do pytania 3.
3. Czy acquirer pisemnie zaakceptował redukcję zakresu dla tego rozwiązania E2EE?
   • TAK → stosuj uzgodniony zakres, zachowaj korespondencję jako dowód dla oceny PCI DSS.
   • NIE → traktuj środowisko jak standardowe (pełny zakres, zwykle SAQ D lub ocena QSA).\

Perspektywa dostawcy:

1. Czy Twoi klienci rozliczają się z wieloma acquirerami lub oczekują SAQ P2PE?
   • TAK → celuj w pełną walidację P2PE; rozważ NESA jako etap pośredni.
   • NIE → przejdź do pytania 2.
2. Czy rozwiązanie spełnia dziś kluczowe wymogi P2PE (POI z SRED, HSM w deszyfracji, zarządzanie kluczami wg Domeny 5)?
   • TAK → NESA szybko udokumentuje dojrzałość i wesprze sprzedaż do czasu pełnej walidacji.
   • NIE → zacznij od analizy luk względem standardu P2PE, zanim zamówisz jakąkolwiek formalną ocenę.

Patronusec przeprowadza analizę luk rozwiązań szyfrujących względem standardu PCI P2PE – dostawca otrzymuje mapę braków w podziale na domeny oraz realistyczny szacunek drogi do NESA lub pełnej walidacji.

Mit i fakt: co się myli w temacie P2PE, E2EE i NESA?

MIT: E2EE daje merchantowi taką samą redukcję zakresu PCI DSS jak P2PE, bo szyfrowanie jest identyczne.
FAKT: Kryteria kwalifikacji do SAQ P2PE wymagają rozwiązania wpisanego na listę PCI SSC. Dla E2EE każdą redukcję kontroli musi indywidualnie zaakceptować acquirer i nie ma gwarancji, że to zrobi.

MIT: NESA to certyfikacja „P2PE light”, po której rozwiązanie trafia na listę PCI SSC.
FAKT: NESA nie kończy się żadnym wpisem na listę ani akceptacją PCI SSC. To dokument P2PE QSA opisujący luki względem standardu, który merchant może przekazać swojemu QSA i acquirerowi.

MIT: Wdrożenie walidowanego P2PE całkowicie zwalnia merchanta z PCI DSS.
FAKT: Merchant nadal podlega PCI DSS – wypełnia SAQ P2PE (21 pytań w v4.0), odpowiada m.in. za fizyczną ochronę terminali i przestrzeganie PIM.

MIT: Skoro rozwiązanie jest na liście PCI SSC, każda konfiguracja terminala u merchanta jest objęta walidacją.
FAKT: Listing obejmuje konkretne modele POI, wersje firmware i aplikacje. Wdrożenie wariantu spoza listingu pozbawia merchanta prawa do SAQ P2PE.

---

FAQ – Różnice między P2PE a E2EE

---

Warto przeczytać

Logiczna ścieżka lektury dla tematu szyfrowania płatności:

1. P2PE – przewodnik po rozwiązaniach płatniczych – fundament: jak działa P2PE i z czego składa się rozwiązanie.
2. Zakres certyfikacji PCI DSS – od czego zacząć i jak go określić – jak szyfrowanie wpływa na granice środowiska CDE.
3. MPoC, SPoC i CPoC – rewolucja w płatnościach mobilnych – co się dzieje, gdy terminalem staje się smartfon.
4. Ile kosztuje certyfikat bezpieczeństwa PCI – koszty formalnych ocen w ekosystemie PCI.

---

Szyfrowanie płatności a zakres PCI DSS – bezpłatna konsultacja

Patronusec jako akredytowany QSA doradza dostawcom rozwiązań szyfrujących i merchantom w projektach PCI DSS oraz PCI P2PE. Jeśli rozważasz walidację rozwiązania lub chcesz zweryfikować wpływ szyfrowania na Twój zakres zgodności, umów bezpłatną konsultację.

Umów konsultację | Certyfikacja PCI DSS | Analiza luk PCI