Natywne karty są powszechnie nazywane "zamkniętymi" - po wyprodukowaniu nie można wprowadzać żadnych zmian w ich systemie operacyjnym, czyli nie można zmienić raz ustalonej funkcjonalności. W przypadku chęci wprowadzenia zmian (np. dodania funkcji nie przewidzianej na początku) trzeba wprowadzić nowy produkt, a karty już wydane nie będą mogły uzyskać nowych funkcji (czyli jedynie można je wymienić na nowe). I tu dochodzimy do zasadniczej sprzeczności z intencją polskiego projektu, który zakłada dodawanie z czasem nowych funkcji w postaci danych lub aplikacji do kart będących już w użyciu. Jest to potwiedzone w par. 13 ust 2 Ustawy, który stanowi że "warstwa elektroniczna dowodu osobistego może zawierać dane i aplikacje inne niż określone w ust.1 [...]".

Dla kart natywnych można jedynie dopisywać nowe dane, nie można natomiast dodawać aplikacji realizujących nowe funkcje logiczne.

Znając to ograniczenie kart natywnych, opracowano standard systemu operacyjnego JavaCard. Przede wszystkim jest to standard otwarty, a zatem dostępny dla każdego, co skutkuje istnieniem wielu firm dostarczających i rozwijających produkty zgodne z tym standardem (w efekcie czego istnieje co najmniej kilkanaście takich renomowanych na całym świecie). JavaCard to zunifikowana platforma wirtualna w mikroprocesorze, pozwalająca na uruchamianie oprogramowania (aplikacji) - tzw. apletów, realizujących określone funkcje dla użytkownika końcowego (jak np. podpis elektroniczny, bezpieczne przechowywanie danych personalnych, karta płatnicza czy portmonetka). Cały kod wykonywalny (oprogramowanie) karty Java składa się z dwóch elementów - systemu operacyjnego JavaCard i apletów (aplikacji). Ponieważ aplety mogą być umieszczane w pamięci modyfikowalnej tzw. EEPROM, czyli że można je ładować i kasować, to jest to równoznaczne z możliwością zmieniania funkcji logicznych konkretnej karty z zainstalowanym w niej procesorem. Jeden aplet karty Java działa zatem jak jedna karta natywna, czyli że w konsekwencji w jednej karcie Java można "umieścić" kilka kart natywnych, nawet o zupełnie różnych funkcjach. W szczególnym przypadku karta Java może działać jak karta natywna - jeśli będzie posiadać tylko jeden aplet, a możliwość ładowania kolejnych apletów będzie fabrycznie zablokowana.

Jednak w praktyce i z założenia karta Java posiada kilka apletów, każdy przeznaczony do innych celów, ułatwiając tym samym zarządzanie kartą i jej aplikacjami. W przypadku potrzeby modyfikacji jednej aplikacji nie zaburza się funkcjonowania pozostałych. Dla pl.ID ma to znaczenie choćby w odniesieniu do aplikacji KUZ (karty ubezpieczenia zdrowotnego), zarządzanej przez NFZ - może np. zaistnieć potrzeba skasowania starego i wgrania nowego, zaktualizowanego apletu KUZ. Inny przykład to potrzeba migracji eID do nowej generacji, gdzie zmienia się jeden z apletów. Wtedy inne aplety pozostają bez zmian i nie wpływa to na infrastrukturę IT z nimi współpracującą.

Według podobnej koncepcji co JavaCard działają też nowocześniejsze od nich karty Multos, w Europie mało jeszcze rozpowszechnione.

Inną ważną cechą kart typu otwartego jest to, że bez względu na dostawcę platformy, każdy inny podmiot może samodzielnie tworzyć oprogramowanie dla nich. W tym miejscu należy się odnieść do projektu pl.ID. Otóż w przypadku aplikacji realizującej funkcję Karty Ubezpieczenia Zdrowotnego, NFZ może np. zlecić wykonanie apletu na zamówienie firmie trzeciej - Fundusz nie będzie skazany na skorzystanie z usług monopolisty-dostawcy platformy systemu operacyjnego i tym samym może uzyskać efekt konkurencyjności i korzystniejszą cenę realizacji. To samo może dotyczyć wszystkich innym nowych funkcji, o których mowa w par. 13.2 Ustawy.

Kolejną zasadnicza zaletą kart typu otwartego jest możliwość dodawania oprogramowania z nowymi funkcjami także dla kart już wydanych. W pl.ID - a mówimy to o horyzoncie nawet i 20 lat funkcjonowania dokumentów- taka potrzeba może realnie zaistnieć w przypadku aplikacji KUZ oraz naturalnie dla wszystkich innych nie przewidzianych dzisiaj funkcji. Zgodnie z zapisami Ustawy, par. 13 ust. 1, warstwa elektroniczna dowodu zawiera jedynie "przestrzeń na zamieszczenie danych służących do wykorzystania dowodu osobistego jako karty ubezpieczenia zdrowotnego", co oznacza, iż dowód nie musi posiadać aplikacji KUZ w momencie jego wydania konkretnej osobie. Wiedząc, iż NFZ ma swoje własne wymagania dla tej aplikacji, może być nie realne dostarczenie karty z systemem operacyjnym spełniającym wszystkie wymagania NFZ na czas (pamiętajmy, o czym boleśnie zapomniało MSWiA, iż produkt musi być gotowy na dlługo przed realizacją dostaw, np. w celu jego przetestowania czy certyfikacji bezpieczeństwa). Zatem możliwośc dodania aplikacji NFZ na karcie Java po jej wyprodukowaniu nie spowoduje kolejnych opóźnień projektu pl.ID, który i tak był już wielokrotnie przesuwany…