Deutsche Unternehmen lieben Formulare. Sie lieben sie so sehr, dass sie daraus Weltbilder bauen. Der Lebenslauf wird zum Datenpaket, die Bewerbung zum Upload, die Eignung zur Checkbox. Und weil das Leben bekanntlich zu kurz ist, um Dinge zu verstehen, die man auch einkaufen kann, wird die erste Selektionsinstanz an ein ATS1 System delegiert, das mit majestätischer Konsequenz genau jene Kandidaten aussiebt, die den Begriff Integrität2 nicht bloss buchstabieren, sondern technisch leben.
Das ist keine Pointe. Das ist Alltag: In grob 70 bis 75 Prozent aller Bewerbungen scheitert bereits der Dateiupload. Grund: Signatur. Grund: Schreibschutz. Grund: Passwortschutz.3 Also ausgerechnet jene Mechanismen, die in einem vernünftigen Universum als minimale Hygiene gelten sollten, werden im HR Fliessbandprozess zur Stolperfalle, und zwar nicht zufällig, sondern systemisch.
Ein ATS ist, nüchtern betrachtet, eine Pipeline: Datei annehmen, Inhalt extrahieren, Text normalisieren, Felder mappen, Schlüsselwörter zählen, Score berechnen, Mensch erst dann bemühen, wenn die Maschine freundlich nickt. Das ist die Ideologie dahinter: Skalierung. Nur ist Skalierung ohne Urteilskraft bloss das Hochdrehen einer Drehorgel.
PDF ist in diesem Kontext kein Dokument, sondern ein Containerformat mit reichlich Historie, reichlich Ecken, reichlich Footguns. Viele ATS Implementierungen nutzen Standardbibliotheken, weil niemand in HR Budgets Lust hat, eine eigene PDF Engine zu pflegen. Die üblichen Verdächtigen in der Java Welt sind PDFBox4 und Tika5, also genau die Werkzeuge, die in Unternehmenssuche, DMS6, Indexierung, Compliance Scans seit Jahren herumgereicht werden. Und diese Werkzeuge reagieren auf Verschlüsselung nicht romantisch, sondern deterministisch: Verschlüsselt ist verschlüsselt. Ende der Diskussion.7
Das ist der Kern des Missverständnisses, das sich dann als fehlerhafte Antwort materialisiert: Ein ATS muss nicht wie macOS Preview handeln. Es muss nicht irgendwie schon gehen. Es muss sicher, wiederholbar, policy konform funktionieren. Und sobald ein PDF signalisiert, dass es verschlüsselt ist oder Rechtebits gesetzt sind, schalten viele Pipelines auf Abwehr, nicht auf Kulanz.
Von PDF Passwortschutz
Beim Standard Security Handler eines PDFs existieren typischerweise zwei Passwörter: User Password zum Öffnen und Owner Password für Vollrechte, also auch zum Ändern von Permissions. Das ist kein esoterisches Detail, sondern die Spezifikation im Alltag.8
Hier liegt die erste Ironie: Ein PDF kann passwortgeschützt sein, ohne dass ich beim Öffnen ein Passwort eingeben muss. Etwa dann, wenn kein User Password gesetzt ist, aber ein Owner Password, um Rechte wie Drucken, Kopieren, Text extrahieren oder Bearbeiten zu steuern. Das Dokument ist dann kryptographisch verschlüsselt, aber für jeden lesbar, der es öffnet, nur eben mit Restriktionen, die eher an höfliche Hinweise als an Sicherheit erinnern. Manche Tools sagen das sogar explizit: Ohne User Password ist das PDF zwar verschlüsselt, aber frei öffnbar; Restriktionen lassen sich in vielen Umgebungen trivial entfernen.9
Was macht nun ein Parser? Er sieht encrypted, muss also einen Entschlüsselungspfad einschlagen. Und selbst wenn er das leere Passwort probiert, bleibt das Problem der Rechtebits: Darf ich extrahieren, darf ich normalisieren, darf ich indexieren? PDFBox beschreibt dieses Feld sehr uncharmant: Wenn das Bit „cannot extract text“ gesetzt ist, braucht man zum Extrahieren die Owner Autorisierung, sonst gibt es eben keine Extraktion.10
Ein ATS, das sich an so eine Policy hält, ist nicht dumm, sondern konsequent. Dumm ist, dass HR Prozesse diese Konsequenz nicht antizipieren und dann so tun, als sei der Kandidat das Problem.
Von macOS Preview
Unter macOS können geschützte PDFs bearbeitet werden. Ja. Das geht. Apple dokumentiert sogar, wie man in Preview ein Owner Password setzt und granulare Permissions vergibt oder entzieht.11
Nur beweist diese Beobachtung nicht, dass Schutz sinnlos wäre. Sie beweist, dass PDF Permissions keine DRM12 sind, sondern ein Access Control Mechanismus, der vom Viewer freiwillig respektiert wird, und der in der Realität oft umgangen werden kann, indem man in eine neue Datei exportiert oder druckt. Der technische Punkt ist banal: Die Integrität des Inhalts wird dadurch nicht kryptographisch an die Datei gebunden, sondern nur die Zugriffssteuerung. Wer ernsthaft verhindern will, dass ein Empfänger bearbeitet, braucht ein anderes Paradigma, etwa echtes DRM, was in Bewerbungsprozessen zum Glück noch nicht der Normalfall ist.
Und damit sind wir bei dem Teil, der mich als Sicherheitsmensch nicht nur nervt, sondern intellektuell beleidigt: Ich setze diese Mechanismen nicht, weil ich glaube, ich könnte damit den Endgegner Preview besiegen. Ich setze sie, weil ich genau weiss, was sie leisten und was nicht. Sie sind ein Signal: Diese Datei ist ein Artefakt, dessen Inhalt unverändert ankommen soll. Und wenn er verändert wird, soll es auffallen.
Von digitalen Signaturen
Eine digitale PDF Signatur ist kein „Schmuck“. Sie ist eine kryptographische Zusage: Der signierte Bytebereich ist genau dieser, und nicht ein Bit mehr oder weniger. Technisch wird das in PDFs üblicherweise mit einem reservierten ByteRange gelöst; die Signatur deckt den Inhalt ab, und jede nachträgliche Änderung, die diesen Bereich tangiert, invalidiert die Signatur.13
Dass PDFs „incremental updates“ unterstützen, macht die Sache anspruchsvoller, nicht einfacher: Man kann neue Revisionen anhängen, ohne alte Bytes zu überschreiben. Für Signaturen ist das ein zweischneidiges Schwert. Die seriöse Welt nutzt das für Langzeitvalidierung und Ergänzungen, ohne die ursprüngliche Signatur zu brechen, wenn es korrekt gemacht ist.14
Wenn also jemand sagt: „Aber du kannst es doch trotzdem bearbeiten.“ Ja, natürlich. Bearbeiten ist immer möglich. Die Frage ist: Was passiert danach? Bei einer sauber validierten Signatur passiert das einzig Richtige: Der Validator sagt „nicht mehr unverändert“, und genau so soll es sein. Die Signatur ist kein Schloss, sie ist ein Alarmdraht.
Und jetzt kommt die Tragikomödie: ATS Systeme verwechseln Alarmdraht mit Stolperfalle. Sie sehen Signatur, sehen verschlüsselt, sehen Policy Bits, und statt den Menschen zu fragen oder einen sauberen Zweitpfad anzubieten, werfen sie die Bewerbung aus dem System. Der Kandidat ist dann nicht zu sicher, sondern zu unbequem.
Vom Murks
Wer programmiert so etwas? Meist niemand mit böser Absicht, sondern ein Gemisch aus Kostendruck, Haftungsangst und Sicherheitsabteilungen, die gelernt haben, dass Dateiparser eine wunderbare Angriffsfläche sind. Das ist nicht hypothetisch. In 2025 wurden erneut kritische Schwachstellen im PDF Parsing Umfeld von Apache Tika diskutiert, mit der erwartbaren Empfehlung: Parser abschalten, Angriffsfläche reduzieren.15
Und sobald Security Leute am Tisch sitzen, passiert etwas sehr Menschliches: Man definiert eine Policy, die in einem Corporate Threat Modell sauber wirkt, und drückt sie dann ohne jede Differenzierung in einen Massenprozess. Verschlüsselte PDFs sind ein Problem, weil Content Scanner „active content detection“ betreiben wollen, also XFA, JavaScript, eingebettete Dateien, was auch immer, und wenn das Dokument verschlüsselt ist, kann der Scanner nicht inspizieren. Ergebnis: Block. SAP SuccessFactors beschreibt dieses Muster sogar explizit: Wenn die Inhaltsprüfung aktiv ist und die PDF verschlüsselt, kann die Prüfung nicht validieren, also scheitert der Upload.16
Das ist, wohlgemerkt, intern durchaus rational. Nur kollidiert es mit der Aussenwelt: Bewerbungen sind keine untrusted attachments aus dem Darknet, sondern Bewerbungen. Wer das nicht auseinanderhält, betreibt Sicherheitsfolklore, nicht Sicherheitsengineering.
Von Spezialisten
Jetzt wird es unerquicklich, weil es das nächste Tabu berührt: Rollen wie CISO oder IT Sicherheitsbeauftragter sind keine Fachkraftstellen im Sinne von wir brauchen 30 Leute, die Jira Tickets abarbeiten. Das sind Positionen, die Definitionsmacht besitzen. Sie entscheiden über Risikoappetit, über Kontrollarchitekturen, über Budgetallokation, über Notfallregime, über Lieferkettenhygiene. Sie sind in der Hierarchie dort angesiedelt, wo ein falscher Entscheid nicht bloss ein Bug ist, sondern ein Vorfall, eine Anzeige, ein Business Desaster.
Angebot und Nachfrage sind dort oben kein Massengeschäft. Der Markt ist dünn, die Anforderungen sind asymmetrisch, der Impact ist brutal. Wer wirklich so tut, als müssten für solche Rollen tausende Dossiers automatisiert vorselektiert werden, verrät bereits damit, dass er das Profil nicht verstanden hat. Oder dass er es nicht verstehen will, weil Verstehen unbequem ist.
Und ja, obendrein drängt sich die Frage auf, ob diese Stellen in jedem Fall real sind oder eher jene hübschen Attrappen, die man ausschreibt, damit der Organigrammtext stimmt und das Employer Branding nicht weint. Ich habe dieses Phänomen, unter dem Etikett „Ghost Jobs“, bereits an anderer Stelle seziert.17
Von Strafen
In einem halbwegs intakten System würde ein signiertes, sauber strukturiertes PDF als positives Signal gelesen: Dieser Mensch arbeitet präzise, denkt in Beweisketten, kennt Authentizität nicht als PowerPoint Wort, sondern als Betriebsmittel. In der HR Realität wird das Gegenteil daraus. Der Prozess ist so gebaut, dass er für Durchschnittlichkeit optimiert ist. Alles, was aus dem Raster fällt, wird nicht verstanden, also verworfen.
Das ist ein Selektionsmechanismus mit perverser Eleganz: Wer sich Mühe gibt, verliert. Wer stumpf Word hochlädt, gewinnt. Wer Metadaten sauber hält, wird ausgebremst. Wer kryptographische Hygiene zeigt, erzeugt „Upload Error“. Der Output dieser Maschine ist vorhersagbar: Sie selektiert nicht Kompetenz, sondern Konformität.
Und damit bleibt am Schluss die Sorte Kandidat übrig, die in solchen Systemen immer übrig bleibt: rhetorisch glatt, semantisch elastisch, moralisch flexibel, fachlich dünn. Menschen, die in Meetings glänzen, weil sie das Vokabular beherrschen, nicht weil sie die Materie tragen. Bullshitter, die in Folien denken, nicht in Systemen.
Von Bräsigkeit als Organisationsprinzip
„Deutsche Bräsigkeit“ ist kein Charakterfehler einzelner Personen. Sie ist Prozessdesign. Man baut Abläufe, die so tun, als könne man Komplexität wegstandardisieren, und wundert sich dann, wenn man am Ende nur noch standardisierte Köpfe bekommt.
Der Schaden entsteht zuerst unsichtbar: Ein Unternehmen merkt nicht, dass es seine besten Kandidaten an der Eingangstüre verliert, weil niemand auf die Idee kommt, eine Metrik zu erheben wie „Wie viele Bewerbungen scheitern technisch am Upload“. Danach wird er sichtbar: Man besetzt Sicherheitsrollen mit Leuten, die Risiko in Ampelfarben ausdrücken, statt es zu modellieren. Später wird er teuer: Incident Response wird zur Theaterprobe, Audits werden zu Ritualen, und die Firma erklärt sich die Welt dann mit „Fachkräftemangel“, während sie in Wahrheit einen Kompetenzmangel produziert hat.
Es gibt diesen Satz: „First-rate people hire first-rate people; second-rate people hire third-rate people.„18 Das ist keine Mystik, sondern eine Beobachtung über Selektionsprozesse. Wer selbst nicht versteht, was er sucht, baut Filter, die das Verständnis ersetzen sollen. Diese Filter finden dann Leute, die genau zu solchen Filtern passen. Das Resultat ist ein geschlossenes System aus Mittelmass, das sich selbst reproduziert.
Das eigentlich Bittere ist: Das wäre vermeidbar. Ein ATS könnte zwei Uploadpfade anbieten, einen für maschinenlesbar, ungeschützt und einen für signiert, bitte manuell prüfen. Man könnte Regeln definieren, die bei bestimmten Rollen das automatisierte Aussondern abstellen. Man könnte Security und Recruiting so verheiraten, dass Sicherheit nicht zur Absurdität verkommt. Man tut es nicht. Man will es nicht. Man lässt lieber das System laufen und nennt die Kollateralschäden Effizienz.
Und so katapultieren sich jene Unternehmen, die sich gern als Spitzenunternehmen etikettieren, ausgerechnet an der Meta Ebene des Personalprozesses schrittweise in die Bedeutungslosigkeit. Nicht weil ihnen Technik fehlt. Nicht weil ihnen Geld fehlt. Sondern weil ihnen die Demut fehlt, anzuerkennen, dass man Spitzenrollen nicht per Fliesbandlogik findet, und dass ein Prozess, der Kompetenz aussiebt, am Ende genau das bekommt, was er verdient. Aufrecht in den totalen Untergang. Weiter. Immer weiter.
- https://www.sap.com/germany/products/hcm/recruiting-software/what-is-an-applicant-tracking-system.html ↩︎
- https://coresecret.eu/2025/12/08/vom-sicherheitsalphabet-cia-kgb-die-cap/ ↩︎
- https://taggd.in/hr-glossary/applicant-tracking-system/ ↩︎
- https://pdfbox.apache.org/ ↩︎
- https://tika.apache.org/ ↩︎
- https://de.wikipedia.org/wiki/Dokumentenmanagement ↩︎
- https://pdfbox.apache.org/docs/2.0.5/javadocs/org/apache/pdfbox/pdmodel/PDDocument.html ↩︎
- https://manuals.setasign.com/setapdf-core-manual/standard-encryption/ ↩︎
- https://pdfcpu.io/encrypt/encryptPDF.html ↩︎
- https://pdfbox.apache.org/2.0/faq.html ↩︎
- https://support.apple.com/de-de/guide/preview/prvw587dd90f/mac ↩︎
- https://de.wikipedia.org/wiki/Digitale_Rechteverwaltung ↩︎
- https://www.eideasy.com/blog/pdf-pades-external-digital-signatures-using-etsi-cades-detached ↩︎
- https://pdfa.org/wp-content/uploads/2020/07/2020-10-07_PDF-Signature-Validation_comp.pdf ↩︎
- https://www.infoworld.com/article/4102677/apache-tika-hit-by-critical-vulnerability-thought-to-be-patched-months-ago-2.html ↩︎
- https://userapps.support.sap.com/sap/support/knowledge/en/3332434 ↩︎
- https://coresecret.eu/2025/12/15/vom-land-der-wirbellosen/ ↩︎
- https://www.brainyquote.com/quotes/leo_rosten_143374 ↩︎