Security Token and Electronic Notifications: Updated Analysis (2026)

Technical‑Legal Framework, Official SCBA Verification, and Modernization Proposals

0. Preliminary note: What PyNE means

PyNE stands for “Presentaciones y Notificaciones Electrónicas” (Electronic Filings and Notifications), the secure web portal of the Supreme Court of the Province of Buenos Aires (SCBA). Its current version, in force since November 1, 2021 under Agreement No. 4013 and amendments, allows court officers, lawyers, and judicial bodies to exchange legally valid electronic communications.

1. Conceptual foundations and legal framework

The PyNE‑SCBA system requires, for obtaining and using the security token, interaction with a web portal that—despite improvements since 2016—still does not list GNU/Linux among its officially supported platforms. This situation persists in 2026 with technical and regulatory nuances analyzed below, in light of official SCBA sources (PyNE system requirements).

From a legal standpoint, it is essential to distinguish between digital signature and electronic signature under National Law No. 25.506. The former enjoys an iuris tantum presumption of authorship and integrity (arts. 7 and 8), whereas the latter—negatively defined as one lacking any of the legal requirements to be considered digital (art. 5)—requires supplementary proof if contested. This distinction is more relevant than ever, since the SCBA has ordered the complete replacement of electronic signatures with digital signatures under a timeline whose final milestone is August 1, 2026 (SCBA notice on the timeline).

Article 40 of the Civil and Commercial Procedure Code (text according to Law 14.142) established the mandatory electronic procedural domicile, regulated by SCBA Agreements 3540/11, 3399/08, 3989 (which created the Electronic Domicile Registry, endorsed by Law No. 15.230) and 4013 (new PyNE Regulations). The principle of technological neutrality —recognized by legal doctrine and by various normative instruments, including the general principles that inform Law 25.506 on Digital Signature, Law 27.078 (Argentina Digital) regarding technological non‑discrimination, and Decree 512/2009 which promoted the Digital Agenda Strategy— together with the guarantees of Art. 18 of the National Constitution, requires that the implemented means do not create unjustified barriers to access to justice.

2. Current status of the PyNE‑SCBA portal (official 2026 verification)

According to official information published by the SCBA (PyNE system requirements), the Electronic Filings and Notifications Portal in its current version (v6.0) works on the following operating systems and browsers:

Key observation: The SCBA does not list GNU/Linux among supported platforms. However, as will be shown below, the technical component required to operate (SETCCE proXSign) is indeed compatible with Linux. The limitation is therefore one of support policy, not technical impossibility (SETCCE proXSign official FAQ).

Important: Since September 30, 2020, the portal no longer supports Windows XP, Windows Vista, Windows 7, Windows 8, or versions of Internet Explorer prior to 11.

3. The real technical component: SETCCE proXSign and its Linux support

The historical limitation of the PyNE‑SCBA portal no longer lies in ActiveX controls (technology discontinued by Microsoft since 2015). The component that currently manages encrypted communication between the browser and the cryptographic token is SETCCE proXSign, developed by the Slovenian company SETCCE (setcce.com).

3.1. Platforms supported by SETCCE proXSign (official manufacturer verification)

According to the manufacturer’s official documentation (SETCCE proXSign FAQ):

Main finding: SETCCE proXSign—the component the SCBA requires to operate PyNE—does have a native version for GNU/Linux, with official support for Ubuntu 22.04 LTS and 23.04, Fedora 37 and 38. Additionally, via AppImage it works on Debian 11/12 and other distributions. Digital certificates can be installed in the NSS store of Firefox or Chrome (SETCCE proXSign FAQ). Therefore, there is no technical impediment for the SCBA to include GNU/Linux in its list of supported platforms. The exclusion is a support‑policy decision, not a technological limitation.

3.2. Full requirements to operate PyNE (confirmed by SCBA)

According to the official SCBA documentation (PyNE Wiki), operating PyNE requires:

1. Approved USB token with its driver installed.
2. Electronic signature certificate issued by the SCBA or digital signature certificate issued by AC-ONTI (as of 01/03/2025, only the latter).
3. Root certificates of the SCBA and AC-ONTI installed in the browser.
4. SETCCE proXSign add‑on installed and running.
5. Individual electronic domicile registered in the RDE.

4. Transition timeline: electronic signature → AC‑ONTI digital signature

Through Resolution SC No. 1682/24 and within the framework of Agreement No. 4150, the SCBA approved the implementation schedule for the complete replacement of electronic signatures with digital signature certificates (SCBA notice of 30/08/2024):

Implication for the physical token: The AC‑ONTI digital signature inexorably requires a cryptographic token. Unlike the SCBA electronic signature—which could originally be stored in software—the AC‑ONTI digital signature must reside in secure hardware. This reinforces the need for the token ecosystem to be compatible with all platforms, including GNU/Linux.

Additionally, through Resolution SC No. 459/23, an electronic domicile linked to a digital signature certificate was enabled for external natural persons (ad‑hoc court officers, third parties) who are not parties to the proceedings and are not members of a bar association, under the designation CUIL@externos.notificaciones.

5. Approved token devices and installation procedure

5.1. Tokens currently required for AC‑ONTI

According to information from professional associations (COLPROBA), the token models suitable for hosting the AC‑ONTI digital signature are:

• ePass2003 (EnterSafe) — CCID compatible, works on Linux
• SafeNet 5110+ (Plus) — requires proprietary middleware
• Athena IDProtect — CCID compatible, works on Linux

5.2. Installation on Ubuntu 24.04 / Debian 12

For CCID tokens (ePass2003, Athena IDProtect, Feitian, mToken, UniMate):

#!/bin/bash
# Base installation for CCID‑compatible tokens + SETCCE proXSign
sudo apt update
sudo apt install -y pcscd libccid opensc pinentry-gtk2 libnss3-tools

# Start and enable PC/SC service
sudo systemctl enable --now pcscd

# Verify USB device detection
lsusb | grep -iE 'athena|enter|feitian|mtoken|unimate|epass'

# Scan connected PC/SC readers (Ctrl+C to stop)
pcsc_scan

# Install SETCCE proXSign (download AppImage from official site)
# wget https://public.setcce.si/proxsign/update/linux/SETCCE_proXSign-latest.AppImage
# chmod +x SETCCE_proXSign-latest.AppImage
# Run: ./SETCCE_proXSign-latest.AppImage

# Configure PKCS#11 module in Firefox:
# Path: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
# Firefox → Preferences → Privacy & Security → Certificates → 
#           Security Devices → Load

Copy commands

6. Case studies: implementation scenarios (updated 2026)

We analyze three representative scenarios in light of the verified official information:

• Case A (Windows 10/11 + Chrome user): Functional access to the PyNE portal. Installs SETCCE proXSign for Windows, the token driver, and the root certificates. The portal works as documented by the SCBA.
• Case B (Ubuntu 24.04 LTS + Firefox user): The token is detected at the system level (pcsc_scan, opensc-tool). SETCCE proXSign for Linux is installed and runs correctly. However, the PyNE portal may deny access because GNU/Linux is not on the official SCBA list of supported platforms, even though the technical component works.
• Case C (Debian 12 + Chrome user): Similar situation to Case B. SETCCE proXSign works via AppImage. The barrier is the SCBA’s support policy, not technology.

Updated conclusion: Unlike the situation in 2016—when the portal depended on ActiveX controls incompatible with any non‑Windows system—in 2026 the barrier is not technical but one of approval. The SETCCE proXSign component works on Linux, CCID and PKCS#11 drivers are standard, and Chrome and Firefox browsers are compatible. The SCBA simply has not included GNU/Linux in its list of supported platforms. This constitutes an administrative barrier that could be overcome by an IT policy decision, without the need for additional technical development.

7. Adaptive authentication proposal and roadmap

The finding that SETCCE proXSign is already Linux‑compatible reinforces but does not replace our adaptive authentication proposal. Coexistence of both solutions would allow:

• Immediate: Request that the SCBA officially approve GNU/Linux, given that the SETCCE proXSign component already supports it.
• Short term (2026): Pilot of adaptive authentication for party filings that do not require the highest signature level, reducing dependence on the physical token.
• Medium term (2027): Progressive migration to WebAuthn and WebCrypto as browser‑native alternatives, eliminating the need for third‑party add‑ons.
• Long term (2028+): Full interoperability based on W3C standards.

Basis for the formal note: The SCBA requires a component (SETCCE proXSign) that the manufacturer itself certifies as compatible with GNU/Linux. Yet the SCBA does not include Linux in its official list of supported platforms. This contradiction between technical reality and declared support policy violates the principle of technological neutrality that informs our legal system (Law 25.506, Law 27.078, Decree 512/2009) and unjustifiably restricts access to justice for professionals who use free software. The formal note we propose will request: (a) express approval of GNU/Linux as a supported platform; (b) publication of installation guides for Linux distributions; and (c) progressive adoption of open standards (WebAuthn, WebCrypto) that eliminate dependence on third‑party add‑ons.

📚 Updated links of interest

• PyNE‑SCBA Portal: official system requirements
• Electronic Domiciles Registry (RDE)
• Replacement timeline: electronic signature → digital signature (Res. SC 1682/24)
• Agreement 4013: PyNE Regulations
• Agreement 4150: Signature infrastructure reorganization
• SETCCE proXSign: official FAQ and supported platforms
• National Law 25.506 on Digital Signature
• Provincial Law 15.230 (RDE)
• Official libccid repository
• FIDO2/WebAuthn: Passwordless authentication standard
• Web Cryptography API (W3C)

Annex A: Model formal letter requesting GNU/Linux homologation

The following text may be copied and formatted in your word processor with the page layout, line spacing, and margins appropriate for a legal document.

Copy formal letter

Annex B: Conceptual proposal for a combined tokenless system (for future discussion)

Although the SCBA has set a peremptory timeline culminating on August 1, 2026 with the full migration to AC‑ONTI digital signatures—which requires the use of a cryptographic token—this update would not be complete without setting forth, for academic and propositional discussion, the future feasibility of a combined system that, for certain procedural acts, dispenses with the physical device without compromising legal security.

Basis: Law 25.506 allows simple electronic signatures (art. 5) provided there is a reliable mechanism for identifying the signatory and expressing their will. Risk‑based adaptive authentication (MFA + device binding + immutable logs) can achieve security levels comparable to those of a token, with the advantage of not depending on an object susceptible to loss, theft, or damage, and at a significantly lower economic cost for the professional.

Tentative proposal: In the medium or long term, once the new digital signature ecosystem is consolidated, a «dual‑track» system could be evaluated in which:

• Acts of greater significance (judgments, rulings, interim measures) would continue to require a digital signature with an AC‑ONTI token;
• Routine filings, party briefs, simple notifications, and other acts of lesser procedural impact could be authenticated through an adaptive authentication scheme with a simple electronic signature, provided the professional’s informed consent is recorded and full traceability of the operation is guaranteed.

Advantages:

• Reduction of operating costs for lawyers and professional associations.
• Greater inclusion of professionals in rural areas or with limited resources.
• System resilience in the face of token failures or loss.
• Adoption of international standards (WebAuthn, WebCrypto) that do not depend on specific vendors.

Nature of this annex: This proposal is put forward as input for future technical‑legal debate within professional associations and before the SCBA, and not as an immediate demand or a criticism of the decision to migrate to digital signatures. Its viability will depend on security assessments, independent audits, and the evolution of the applicable regulatory framework.