The LDAP server holds more than usernames and passwords. It holds PII—names, emails, phone numbers, employee IDs—data that can identify a person. When bound to application logic, this can be the most sensitive layer in your stack.
LDAP (Lightweight Directory Access Protocol) is often treated as a simple authentication service. That mistake leaves PII data exposed. Every attribute in an LDAP entry is a potential key to personal identity. This includes cn, mail, telephoneNumber, and custom fields that often expand with business needs. If access controls are too loose, queries can return entire records without limitation.
PII in LDAP is not just static. It changes with each HR update, each profile change, each system integration. Poor schema design and weak ACLs allow unauthorized services to pull fresh personal data every day. Security teams must ensure that every bind operation, search filter, and result parsing steps comply with a strict privacy policy.
Encrypted transport (LDAPS / StartTLS) stops network sniffing. Strong authentication with Kerberos or secure binding prevents credential abuse. But these are not enough. Filter queries to return only required attributes. Audit logs must track who fetched what, and when. Replication to off-prem servers should be encrypted and verified.