No.

BP-AT-003

Scale

1 : 1

Date

2026-05-25

Rev.

A

Werkstatt 4notify · eGovernmentReleased

Blueprint BP-AT-003 of BP-AT-008 · eGovernment

SMSEmailWebhook

ID Austria & Handysignatur as a second factor

Migrating Handysignatur to ID Austria, FinanzOnline integration and the cross-channel 2FA flow

§ AThe problem

Many applications transitioned from Handysignatur to ID Austria only half-heartedly — UI still says ’Handysignatur', SMS copy points to apps that no longer exist, and audit trails use outdated field names. For regulated industries (banks under EBA, insurers under FMA supervision, tax advisors under WT-Verordnung) that's a compliance risk: during an FMA or DPA audit, inconsistent 2FA logs are flagged as a weakness.

§ BMain view

ID Austria has been the unified electronic identity proof in Austria since December 2023. It replaced the Handysignatur (established in 2009) — existing Handysignaturen had to migrate to ID Austria by 5 December 2023 or be deactivated. For applications that send notifications around sensitive identity events (FinanzOnline login, USP authentication, oesterreich.gv.at sign-in, ELGA access), a consistent 2FA flow is required: web login starts the request, a signed push or SMS notification arrives on the user's smartphone, the user confirms with ID Austria PIN or biometrics, and the session is released. 4notify covers the notification side of this flow — verification-code SMS, push tokens, and the subsequent audit log.

§ CParts list

Channel	Primary provider	Fallback
Verification SMS	A1 / Magenta / Drei (BP-AT-002)	TOTP über Authenticator-App
Push Notification	FCM (Android) + APNs (iOS)	SMS-Fallback nach 30 s
Magic Link E-Mail	4notify Mail (DKIM/DMARC)	Resend nach 60 s
Audit Webhook	Signed HMAC-Webhook	Postgres event_log

§ DTolerances

Code lifetime

120seconds

Push wait before SMS fallback

30seconds

Max sign-in attempts

5/ hour

Audit retention

5years (FMA requirement)

Code length

6digits (numeric)

§ ENormative references

E-Government-Gesetz (E-GovG) § 4

Controllers must accept an electronic identity proof issued via ID Austria or other qualified electronic identification means under the eIDAS regulation.

eIDAS-Verordnung (EU 910/2014)

ID Austria meets eIDAS ’high’ assurance level and is EU-notified. Push confirmation counts as ’something the user has'; PIN as ’something the user knows'; biometrics as ’something the user is’.

BWG § 39 (Bankwesengesetz)

Banks must implement strong customer authentication (SCA) under PSD2. ID Austria meets the SCA requirements, but many Austrian banks offer it in parallel to their own app-based solutions — notifications must name the chosen path correctly.

§ FBuild steps

Register push token at app install

At first app launch the FCM/APNs token is sent to the backend, stored encrypted (KMS-bound) and bound to the user_id. On logout the token is revoked.

Login triggers push + prepares SMS fallback

Web login triggers a push immediately. In parallel, a 6-digit verification code is generated and stored in cache for 120 seconds. After 30 seconds with no push confirmation, an SMS containing the code is sent automatically.

Push confirmation with ID Austria PIN

The push opens a confirmation dialog requiring ID Austria PIN or biometrics. Successful confirmation sends a signed callback back to the backend; the backend matches the token against the active session hash and releases the session.

Audit entry with method + outcome

Every 2FA attempt (push_sent, sms_fallback, code_entered, code_correct, code_wrong, expired, withdrawn) is stored as a separate row in event_log. This matters for FMA audits that look back to verify the SCA flow was consistently applied.

§ GTest procedure

Test procedure: (1) Sign in test user in the web — verify push arrives in the app within 3 seconds. (2) Don't confirm the push, wait 30 seconds — an SMS with a 6-digit code must arrive. (3) Enter the code in the web frontend — session released, audit_log contains rows `push_sent` + `sms_fallback` + `code_entered` + `code_correct`. (4) Test with wrong code — row `code_wrong`, after 5 failed attempts login must be blocked for one hour. (5) Test with an expired code (> 120 s) — row `expired`, code rejected.

§ HCode

bash
curl -X POST https://api.4notify.net/v1/auth/2fa/dispatch \
  -H "Authorization: Bearer $API_KEY' \
  -H "Content-Type: application/json' \
  -d '{
    "user_id': 'u_at_4711",
    "session_hash': 'sha256:b1946ac92492d2347c…",
    "channels': ['push", "sms"],
    "push_token': 'fcm:eYj1z...",
    "sms_recipient': '+436641234567",
    "code_length": 6,
    "code_ttl_seconds": 120,
    "fallback_after_seconds": 30,
    "audit_purpose': 'id_austria_login"
  }'

§ ISample message

SMS

ID Austria: your sign-in code for FinanzOnline is 482593. Valid 2 min. Do not share. If in doubt: ID Austria app > block.

§ JCommissioning checklist

Replace all Handysignatur references in the UI with ’ID Austria’
FCM and APNs tokens revoked on logout
Push-to-SMS fallback after 30 seconds wired up
Rate limit: max 5 sign-in attempts per hour enabled
Audit log retains entries for at least 5 years (FMA requirement for banking/insurance)
SMS text contains no clickable link (FMA best practice against phishing)

What 4notify does differently

4notify names methods explicitly — `method: id_austria` vs `method: handysignatur` vs `method: bank_app` — and preserves historical entries across the migration, so FMA auditors get a consistent trail to inspect retroactively.

§ KFAQ

What happens to old Handysignatur logs?

Migrate, don't delete. Existing audit entries with `method: handysignatur` stay in the event_log — auditors expect the unbroken historical trail. New entries use `method: id_austria`. The audit trail stays consistent across the migration cutoff.

Are SMS OTP codes still accepted under PSD2?

Yes, as ’something the user has’ (combined with a password or biometrics). The EBA recommends push confirmation as the safer standard; SMS OTP is increasingly positioned as a pure fallback. 4notify implements both in parallel.

How do I integrate ID Austria with FinanzOnline?

FinanzOnline accepts ID Austria as a sign-in method directly — integration runs server-side through the BRZ portal Bürgerkartenumgebung (BKU). 4notify isn't used for the sign-in itself in this flow but for downstream status notifications (filing received, assessment ready).