Securing the Public Procurement Login: 2FA and ID Austria in Practice — A Recap of “Zwei-Faktor-Authentifizierung und ID Austria” by Dominik Zimmel (Auftragnehmerkataster Österreich)

Why authentication strength matters in public procurement

Trustworthy identities, secure logins, and verifiable electronic submissions are non-negotiable in public procurement. In the session “Zwei-Faktor-Authentifizierung und ID Austria,” Dominik Zimmel (Auftragnehmerkataster Österreich) walked through exactly that junction of usability and security: the product context, a live-like demo of the bid submission flow, and the rollout of stronger sign-in through two-factor identification (2FA) and ID Austria as a login option.

Our key takeaway: the team runs a platform aligned with the full procurement lifecycle, demonstrates end-to-end e-submission—including e-signature via Handysignatur or ID Austria—and then shows how they strengthened the sign-in path. Two measures stood out: 2FA (via email code or an app like Google Authenticator) and the ability to sign in with ID Austria instead of username/password. Operationally, the change hinged on careful time management, timely testing, an “Open-ID coordination” step for going live, and the necessary coordination across IT, software development, and design.

Three products, one process: E‑Vergabe, Vergabeportal, LGU

The session opened by outlining the product landscape in use by contracting authorities and suppliers:

• E‑Vergabe: the interface for public contracting authorities to publish tenders.
• Vergabeportal: the access point for suppliers to find tenders and submit bids.
• LGU (Liste geeigneter Unternehmen): the list and review of companies’ suitability to take on public contracts.

Together, these elements frame the core process: publication, discovery and bid submission, and suitability checks. It’s a useful backdrop for the later security focus: each step depends on digital identity, traceability, and complete, immutable documents.

The demo flow in the Vergabeportal: search, submission, e‑signature

The demo zeroed in on the Vergabeportal and the actual bid submission by a supplier. The session walked through a realistic sequence:

1. Sign in to the portal: A user authenticates to access search and submission features.
2. Search for tenders: The example used the term “Baumeisterarbeiten.”
3. Compose the bid: The form fields were partially prefilled (to keep the demo concise). The user:

• adds the bid data,
• specifies the offer amount (the price for the bid),
• uploads the bid document.

1. Review step: The platform presents a verification screen—does all data look correct, is the price accurate, and is the uploaded file the intended one?
2. E‑signature: The submission is signed electronically “via Handysignatur or ID Austria.” Confirmation follows once the signature is done.
3. Confirmation and documents: After submission, the user sees the relevant files, e.g., the bid protocol.

Two dimensions are obvious here. The login must reliably prove the user’s identity before any submission can occur. Then, the e‑signature cements the bid’s integrity and non-repudiation at the end of the flow.

The project: stronger sign‑in with 2FA and ID Austria

After the demo, the session turned to the security upgrade itself—two additions to harden authentication:

• Two‑factor identification (2FA): “... via email, receiving a code ... or ... an app like Google Authenticator ... enter the code ... after the username and password login.”
• ID Austria as a login option: “... a possibility to log in with ID Austria instead of password and username.”

This dual model gives users a choice: keep using username/password but add a second factor—either an emailed one‑time code or a code from an authenticator app—or bypass passwords entirely by logging in with ID Austria.

Login screens: ID Austria on the left, 2FA on the right

The session showed the sign‑in UI:

• Left side: sign in with ID Austria.
• Right side: the 2FA step for username/password, either via email code or an app‑generated code.

This duality supports different user preferences and organizational contexts: those who already use ID Austria can rely on it as their primary authentication, while others can keep classic credentials and strengthen them with 2FA.

E‑signature at submission, strong authentication at sign‑in — a clean separation

The e‑signature completes the bid submission “via Handysignatur or ID Austria.” The new 2FA and ID Austria login strengthen the earlier stage: authentication to access the portal. That separation—robust sign‑in for access, formal e‑signature at submission—keeps both responsibilities clear and aligned with the workflow.

Project execution: time management, Open‑ID coordination, testing, design

The session emphasized the operational side of landing such a change. Four points stood out:

• Time management and timely testing: “... keeping to the time management ... ensuring testing happens in time ...”
• Open‑ID coordination for going live: “... when moving to production, Open‑ID coordination, production data ...”
• Cross‑team alignment: “... coordination between IT, software development and internal stakeholders.”
• Design fit and user experience: “The design had to be right ... to deliver a great user experience and provide the increased sign‑in security.”

These are the typical waypoints in security rollouts: a clean integration, agreement on productive interfaces, coordinated testing, and UI/UX that makes the additional steps (second factor or redirect to ID Austria) clear and reliable.

What the login decisions imply for engineering

The measures presented in the session translate into practical guidelines for teams in and around public procurement.

1) 2FA as a protective layer on username/password

Two options were shown:

• Email code: a one‑time code sent to the user’s registered email address.
• App code: a code generated by an app like Google Authenticator on the user’s device.

Both raise the bar for attackers while keeping user access workable. The UI must make the choice clear and handle error cases (wrong code, expired code) gracefully.

2) ID Austria as an alternative to passwords

The ability to “log in with ID Austria instead of username/password” was central in the session. Practically, the flow becomes a UI selection between the two modes, a redirect to the ID Austria login, and a return back into the platform. The session depicted these options side by side (ID Austria on the left, 2FA on the right).

3) E‑signature embedded in the submission step

The e‑signature via Handysignatur or ID Austria is baked into the bid submission. After the pre‑submission review step, the user signs, receives confirmation, and sees documents like the bid protocol. This closure is key for traceability and completeness.

The end‑to‑end user journey — and where security steps in

The session made the full process tangible. From an engineering angle, it’s useful to note the exact moments where security and UX work together.

Sign‑in

• Option A: username/password followed by 2FA via email or app code.
• Option B: sign‑in directly with ID Austria (no local password).

In both cases, the platform must keep session state clean and return users to the relevant context (search or ongoing submission).

Search and bid authoring

• The example “Baumeisterarbeiten” showed how discovery is a central part of the process.
• Bid authoring includes completing data, setting the offer amount, and uploading the bid file. Validation, consistent state handling, and a visible pre‑submission review matter here.

Review and e‑signature

• The review screen ensures data, price, and file correctness before the signature.
• The signature itself is carried out “via Handysignatur or ID Austria.”

Confirmation and protocol

• After submission, the user receives confirmation and sees relevant documents like the bid protocol. This feedback loop is critical for user trust and auditability.

Organizational learnings for teams

The session called out the pragmatic success factors for security rollouts:

• Testing in time: If security is to work for users, it must be robust in practice—hence the emphasis on time management and timely testing.
• Open‑ID coordination and production data: Going live requires careful alignment—interfaces, data flows, and configurations must be in place.
• Cross‑team coordination: IT, software development, and internal stakeholders need to sync or user flows will fragment.
• Design quality: “The design had to be right ...” — security steps must be visible, understandable, and supportive.

Concrete takeaways for engineers

Grounded in the session’s content, the following steps stand out for comparable platforms:

• Structure the sign‑in strategy clearly:
• Offer both: ID Austria login and username/password with 2FA.
• Make the choice explicit in the sign‑in UI.
• Implement 2FA options in a user‑comprehensible way:
• Email code as a low‑barrier second factor.
• App code (e.g., via Google Authenticator) as a robust alternative.
• Secure the end of the process:
• Treat e‑signature as an integral part of the submission step.
• Provide immediate confirmation and access to documents (e.g., the bid protocol).
• Plan testing and production alignment:
• Allow runway for test cycles.
• Sort “Open‑ID coordination” and “production data” ahead of time.
• Orchestrate teams:
• Align IT, software development, and internal stakeholders.
• Design the UI/UX so that security steps are clear and smooth.

These takeaways mirror what the session made explicit: strengthen the sign‑in, keep the submission step legally sound, and land the change through disciplined execution across teams and design.

Notable quotes and session highlights

A few lines encapsulate the main thrust:

These capture the dual emphasis on authentication hardening and e‑signature integrity, plus the operational discipline that made the rollout stick.

Conclusion: A solid security upgrade with an end‑to‑end view

“Zwei-Faktor-Authentifizierung und ID Austria” by Dominik Zimmel (Auftragnehmerkataster Österreich) shows how a platform in the public procurement context can raise authentication strength without losing flow. The demo—from login through search, bid authoring, e‑signature, and confirmation—is cohesive. The security upgrade—2FA via email or app code, and ID Austria login as a password alternative—addresses portal access while keeping the submission’s e‑signature cleanly integrated.

With explicit “Open‑ID coordination” for production, on‑time testing, cross‑team alignment, and a UI designed for clarity, the improvements land where they matter most: in daily use. The closing sentiment—challenging but successful—fits the trajectory.

For engineering teams in similar domains, the session offers a clear pattern: reinforce login and closure, make the review step visible before signature, and orchestrate the rollout so that go‑live and user experience stay in lockstep.

• 

  

  Patrick Osika, IT-Leiter bei ANKÖ

  Patrick Osika von ANKÖ spricht im Interview über den Aufbau des IT Teams im Unternehmen, den Ablauf des Bewerbungsprozesses und gibt Einblicke in die technologischen Challenges.

  Watch now

• 

  

  Marek Dusecina, Senior Full Stack Engineer bei ANKÖ

  Marek Dusecina von ANKÖ erzählt im Interview über seinen Background im Programmieren, gibt Einblicke in seine aktuelle Arbeit im Full Stack Engineering und gibt Tipps für Neueinsteiger.

  Watch now
• 

  

  Dominik Zimmel, Product Owner bei ANKÖ

  Dominik Zimmel von ANKÖ spricht im Interview über seine Reise bis hin zur Arbeit als Product Owner, wie sein Arbeitsalltag aussieht und gibt nützliche Tipps für Anfänger.

  Watch now