Can I use SHA256 from BIP39 passphrase for auth credentials?

My idea is to make SHA256 from BIP39 passphrase and split it to two strings.

That's two serious errors from a security design standpoint.

• That's using a fast hash function like SHA-256 to process something aimed at being memorized. Rather, one must use a slow password hash for key streching. These are known a Password-Based Key Derivation function. If at all possible, it must be memory-hard. Recommendable choices include Argon2 or scrypt. While BIP-39's choice of PBKDF2-HMAC-SHA512 with 512 rounds is poor (because HMAC is not memory hard and suitable for massive speedup with ASICs, FPGAs, or GPUs), SHA-256 is about 1000 times faster, thus easier to attack for a password cracker.
• That's splitting the data/entropy of a secret into two independent shorter secrets, that can be separately attacked. Analogy: replacing a 6-digit code to enter a building into two 3-digit codes, one for each of two successive doors. When something secret and memorable must be put to multiple use, the whole secret must enter a Password-Based Key Derivation Function, together with some constant tied to the intended usage, and if at all possible salt.

Note: there may be other mistakes in the design. We can't tell, since security goals and assumptions are not stated.

Can I use SHA256 from BIP39 passphrase for auth credentials?

My idea is to make SHA256 from BIP39 passphrase and split it to two strings.

That's seems to be two serious errors from a security design standpoint.

• That's using a fast hash function like SHA-256 to process something aimed at being memorized. Rather, one must use a slow password hash for key streching. These are known as Password-Based Key Derivation function. If at all possible, it must be memory-hard. Recommendable choices include Argon2 or scrypt. While BIP-39's choice of PBKDF2-HMAC-SHA512 with 512 rounds is poor (because HMAC is not memory hard and suitable for massive speedup with ASICs, FPGAs, or GPUs), SHA-256 is about 1000 times faster, thus easier to attack for a password cracker.
• That's splitting the data/entropy of a secret into two independent shorter secrets, that can be separately attacked. Analogy: replacing a 6-digit code to enter a building into two 3-digit codes, one for each of two successive doors. When something secret and memorable must be put to multiple use, the whole secret must enter a Password-Based Key Derivation Function, together with some constant tied to the intended usage, and if at all possible salt.

Note: there may be other mistakes in the design. And perhaps the above two apparent issues really are mitigated by something. We can't tell, since security goals, assumptions, and detailed design are not stated.